Hacker News Reader

Comment by zwieback | Hacker News Reader

I used to be a 100% C++ programmer in the olden days but over the years C# and Python have pushed my C++ percentage down to maybe 10% super time critical code and some embedded.

RAII is the one thing I really really miss from my C++ days. From what little I know about Rust it seems to promise a more "baked-in" version of RAII so I'm all for it. Haven't found the time to experiment but looking forward to eventually dipping my feet in.

View on HN

I'd argue that RAII is pretty well baked into C++.

For Rust, it's the "Drop" trait that you add onto things which ultimately causes RAII behavior.

You don't need to do it as much with rust as a lot of the reasons for wanting RAII (memory management) are simply handled by the language.

For Rust, it's sort of the "Pit of success" the easy thing to do is the right thing to do. Whereas in C++, it's pretty dang easy to new something up and fail to correctly delete it.

> Whereas in C++, it's pretty dang easy to new something up and fail to correctly delete it.

This is true, but we shouldn't be encouraging people to reach for new/delete these days; auto Foo = std::make_unique<Foo>(args); does the right thing in a surprisngly large number of cases. It's not the only tool available, but it's a really damn good one.

The "Pit of success" and "Pit of failure" aren't really about what's available in a language, it's about what's easy and natural.

I'd argue that in a language with the `new` keyword, nothing is more easy or natural than invoking it. `auto Foo = std::make_unique<Foo>(args);` is absolutely the right thing to do, but would you really be surprised to find `auto foo = new Foo(args);`?

I absolutely agree unique pointers are the right call. They just aren't necessarily the easy or natural call.

The contrast is rust where all ptrs are, by default, unique ptr and the compiler validates that for you.

I've thought before about making a "dialect" of C++ that doesn't add any new fundamental capabilities, but simply changes syntax to make the more modern options easy and natural and make old C features verbose and difficult. For example, using "*" to represent unique_ptr and std::legacy_c_ptr<...> to represent "bare" pointers. Ideally, such a dialect could be fully include-compatible with all existing C++ code (although macros could be difficult), similar to how Rust "editions" or go "language versions" work. If C++ compilers offered a "#pragma modern_defaults" would people be interested in using it?

Not really, one of the reasons people keep using C++ is its legacy.

It is already hard to educate people on modern language features and adoption of static analysers that enforce Core Guidelines.

Who would write the books and teaching materials for #pragma modern_defaults, and ensure it would be accepted into ISO?

Actually in C++ the vast majority of the time, the right thing to do is

    Foo foo{args};

Which is simpler than the other cases, more correct and more performant. The rare few times dynamic allocation of something that is not an array with new is needed is when you have polymorphic types - but then, the user code generally calls a factory function instead of new.

Can we agree that the new "best default" way of instantiating is... pretty damn weird?

    auto foo = std::make_unique<Foo>(args);

Think about explaining this to a new C++ developer.

This will feel much more natural to most developers:

    var foo = new Foo(args);

The "best default" way of instantiating is

    Foo foo(args);

Sometimes an object has to be on the heap as its own separate allocation (rather than on the stack or as a data member), but I notice that some new developers who come to C++ from some other language use the heap way too much.

> Think about explaining this to a new C++ developer.

How's this:

The code allocates and initializes a new Foo instance with args. By using make_unique you guarantee that the destructor is called when foo goes out of scope for any reason.

in my experience, it's almost inevitable that you end up calling some code you don't control that returns raw pointers. better hope you have access to the source or at least some good docs :)

Agreed. That problem existed even before unique_ptr though; there are still some APIs that I use that hand you back pointers that you may or may not need to manage yourself. If you do need to, then unique_ptr + custom deleter is the way to go!

If you are using a relatively recent version of C#, you can get quite close to it, specially now that using can make use of structural typing.

And with help of Roslyn, any type with a "destructor" (aka Dispose) that gets used without a using declaration can be turned into a compiler error.

Reply on news.ycombinator.com