Hacker News Reader

Comment by fnord77 | Hacker News Reader

last time I used C++ was in the mid-2000s. With all the new features since then, I assume the "proper" way/style to right C++ has changed since then?

View on HN

Largest changes (most from C++11, some from C++14 and C++17) are:

- std::unique_ptr and std::shared_ptr (your code should not have any new/delete). It's easy to write code with clearly defined ownership semantics, and I've yet to create a memory leak.

- Proper memory model so that multithreading has defined semantics.

- Lots of syntactic sugar (auto, range-for, lambdas, structured bindings, if constexpr, etc.).

- More metaprogramming tools/fun.

C++11 alone is a very different world compared to what you are probably used to.

Generally good things, but I get triggered when I hear people call metaprogramming "fun." Such is the beginning of all sorts of woes.

Many of the improvements are to make metaprogramming increasingly unnecessary. I practically don't use it at all anymore.

But coding on C++ has become quite fun. Generic lambdas deserve much of the credit.

> - std::unique_ptr and std::shared_ptr (your code should not have any new/delete). It's easy to write code with clearly defined ownership semantics, and I've yet to create a memory leak.

I cannot begin to describe how huge a thing this was for me. I came to C++-17 (just about) from C++-98 -- a language I hated so much, I vowed I would never, ever write anything in it on purpose.

It is a massively different beast today from what it was, but the biggest thing of all is this change in how you deal with memory. It was like going from a particularly annoying and verbose aberation of C to a particularly fast and expressive version of Python.

YMMV, of course. In fact, it may vary to the point of becoming absolutely unrecognizable if you're dealing with a massive legacy codebase. But I have to say, I've become a very big fan in the last few years.

It's strange to even call them the same language, it's even stranger when you consider the same compiler will deal with both subsets of the language. It's at the point where someone tells you something is in C++ and you can't even be sure what that means until you look at their code.

I keep my head down in language war discussions, but when people start the usual round of complaints and ridicule of C++, this is exactly what I think: I'm not sure we're actually talking about the same language.

It's still terribly verbose. C++17 barely started to get templates under control. Look at how many characters you need to say "if" and "true"

Not sure how to understand your concern. Yes, it's not 05AB1E. Yes, namespaces are necessary if you have code bases with millions of LOC. But for the most part, C++ is as verbose as you make your type and variable names.

Do you actually find it verbose to read or also verbose to type? I don't consider the latter an issue since 1. you normally spend much more time thinking than typing while programming, and 2. code is read much more often than it is written.

I believe even with C++98 you could have used boost::shared_ptr and boost::scoped_ptr. The addition to the STL effectively didn't change that much. It's just that when you used C++ back then, they probably weren't considered best practice yet.

More important in my opinion are changes to the language, like lambdas or auto.

Why weren't you using smart pointers before c++11? boost had them, and rolling your own is very easy.

I did the latter for a project that started around 2000 and never looked back.

I think the answer to that is that I wasn't an experienced enough developer at the time to know how to do that. ;)

Some more:

* Hash maps in the standard library (every so often I have to go and look it up to remind myself that no, I’m not imagining things, C++03 really didn’t have hash maps in the standard library, as ludicrous as that sounds)

* Regexes

* Option and Variant types

* Move semantics

And my personal favorite...

* foo<bar<quux>> is no longer a syntax error

C++ doesn't like making arbitrary choices in standard libraries, and there are lots of performance tradeoffs and API shape choices to make in a language like C++ that refuses to make programers pay for anything they don't want.

I don't know if you mean formatting, in which case I don't believe anything has changed (pretty much anything goes) but yes, you can now do for (auto [x, y] : list_of_coordinates()) ... and things like that.

* is now deprecated.

Not formally, but as you were responding to a comment on style: indeed, you don't really need * that often; there are more powerful, safer options in most cases.

But C++ is a systems programming language and * is still quite useful.

This is not even remotely true. Let's say you have:

  std::unique_ptr<foo> m_foo;

How do you pass that into a function that can receive a pointer to foo, but does not require it? The only way to do so is to declare the function to take a foo* and pass it m_foo.get()

In summary, * will never be deprecated until C++ has support for something along the lines of Rust's borrowing and lifetimes.

I am not sure I understand what you mean, but now (c++17) you can use an optional in this case.

> How do you pass that into a function that can receive a pointer to foo, but does not require it?

Same as you would have a function that can receive an `int` but does not require it. Or a receive a `std::vector` but does not require it.

I surmise that you mean "how do you pass any value (pointer or otherwise) into a function that can receive a value but does require it". And I surmise you have before used pointer indirection to pass that value because it has a conventional sentinel value of 0/NULL/nullptr.

You are correct in that optional values did not have a standardized solution, until C++17 std::optional.

If you don't have C++17, I recommend one of the equivalent third-party implementations:

* https://www.boost.org/doc/libs/1_52_0/libs/optional/doc/html...

* https://github.com/akrzemi1/Optional

std::optional does not support references (std::optional<MyVeryLargeType&>) however unlike boost, so this precludes usage with non-copyable types.

That was decided against for now, though I'm not sure why. [1]

In any case, you can use std::optional<std::reference_wrapper<MyVeryLargeType>>.

[1] https://stackoverflow.com/a/26895581

> In any case, you can use std::optional<std::reference_wrapper<MyVeryLargeType>>.

I would frankly give a negative code review to anyone who would do that.

You go from e.g.

    void my_function(T* foo, T* bar, int baz)
    {
      // ...
      foo->stuff(bar, baz);
    }

    void my_function(std::optional<std::reference_wrapper<T>> foo, std::optional<std::reference_wrapper<T>> bar, int baz)
    {
      // ...
      foo->get().call(&bar->get(), z);
    }

this also has more overhead (sizeof(std::optional<std::reference_wrapper<T>>) is twice the size of T* ), and let's not even start talking about calling conventions and the compile time cost of having to include both <functional> and <optional> everywhere.

It's hard to tell, but if T* foo can be NULL (and I assume that it can, though there's no visible indication), your first function is gonna segfault.

It's easy to tell that in the second function.

Second function makes for a better code review.

heh, to say that I originally wrote if(foo) and then replaced it by //... because that was not the point. Also, dereferencing an unset optional is also UB, so it would segfault all the same given the same preconditions.

Yes. The code is equivalent, but it's clear that the second is meant to optional.

The first has no such indication, except hopefully some human-readable comment that the pointer may be NULL.

> The first has no such indication, except hopefully some human-readable comment that the pointer may be NULL.

I don't understand. If the parameter was not meant to be sometimes null it would be a reference; not a pointer. The fact that a pointer is used is the "this may be null" indication.

This is precisely what std::optional is for.

I can't edit my original comment anymore, so I'll just write a clarification in the reply.

Many people have pointed out that C++17 has std::optional. While that's true, I don't think it'll deprecate raw pointers. I'll try to explain why.

Here's an example you can paste, compile and run:

  #include <iostream>
  #include <memory>

  struct foo
  {
    int thingamajig;
  };
  
  void borrow_optional_foo(foo * borrowed)
  {
    if (borrowed != nullptr)
    {
      borrowed->thingamajig = 42;
    }
  }

  int main()
  {
    std::unique_ptr<foo> owned = std::make_unique<foo>();
    owned->thingamajig = 17;
    std::cout << owned->thingamajig << std::endl;
    borrow_optional_foo(owned.get());
    std::cout << owned->thingamajig << std::endl;
    return 0;
  }

If you run it, it should print:

  17
  42

What would it look like if we wanted to use std::optional and get the same behavior?

  #include <iostream>
  #include <functional>
  #include <memory>
  #include <optional>

  struct foo
  {
    int thingamajig;
  };
  
  void borrow_optional_foo(std::optional<std::reference_wrapper<foo>> borrowed)
  {
    if (borrowed)
    {
      borrowed->get().thingamajig = 42;
    }
  }

  int main()
  {
    std::unique_ptr<foo> owned = std::make_unique<foo>();
    owned->thingamajig = 17;
    std::cout << owned->thingamajig << std::endl;
    borrow_optional_foo(std::make_optional(std::ref(*(owned.get()))));
    std::cout << owned->thingamajig << std::endl;
    return 0;
  }

As you can see, there's a tradeoff involved. On the one hand, you get crystal clear, descriptive type: std::optional<std::reference_wrapper<foo>> is clearly an optional reference to foo.

On the other hand, using it is absolutely atrocious: you have to write borrowed->get().thingamajig as opposed to borrowed->thingamajig, and std::make_optional(std::ref(*(owned.get()))) as opposed to owned.get()

Does it work? Absolutely. Is it crystal clear? Indisputably so. Will it deprecate raw pointers? I really, really doubt it, but that's just my opinion.

This is a great reply and I think it echoes what I've seen written elsewhere. For example, this one by Herb Sutter:

https://herbsutter.com/2013/06/05/gotw-91-solution-smart-poi...

Reply on news.ycombinator.com