Modern C++ – RAII (opens in new tab)

With shared_ptr you completely lose track who actually owns an object or when it will get destructed. It encourages sloppy programming and makes code much harder to read and reason about.

Unlike most languages that have ref-counting build in, shared_ptr also doesn't provide anything to deal with cyclic dependencies, so you can end up with memory leaks.

The most important reason however is simply that you don't need it like 99% of the time, unique_ptr provides enough functionality to work just fine as a shared_ptr replacement in most situations. And in the rare cases where you really need a shared_ptr, you can just convert a unique_ptr into one.

For the same reason that you don't use Rc for everything in Rust. Putting all your heap management behind reference counted pointers isn't "that inefficient", no. But if you don't need the direct control over heap behavior, you shouldn't be using C++ (or Rust) in the first place.

Languages with GC-managed runtimes (Java, C#, Go, Swift, et. al.) are actually significantly more performant for almost all heap-bound use cases, actually. Reference counting kinda sucks for typical code.

I take the following approach: - Stack by default - Unique ptr if needed on the heap - Shared ptr if needed to share ownership

Although unique ptr is zero cost after make_unique(), I avoid polluting my heap unnecessarily. I've never benchmarked this though (keeping various objects on stack vs heap as unique ptr and how that impacts memory accesses)

I'm quite junior. Appreciate anyone pointing out if anything I said doesn't make sense.

Because shared_ptr (and also unique_ptr) nudges you towards keeping each object in its own heap allocation, and that quickly gets inefficient with large number of objects. E.g. a handful of large objects managed through shared_ptr is usually fine, but managing many tiny C++ object individually through smart pointers usually isn't. Instead store large groups of objects of the same type and similar lifetime by value in a std::vector (and then maybe put that std::vector behind a smart pointer).

Also if you lean in too much on shared/unique pointers for large amounts of tiny objects you'll most likely end up in a situation where Java-style garbage collection would be more efficient.

E.g. manual or semi-manual memory management is mostly about controlling the overall memory layout of your application's data to improve throughput, reducing the number of individual heap allocations is just a useful side effect.

Yes, it is very inefficient, as it is thread-safe and uses atomic operations internally.

So instead of just accessing memory, you have the cost of cross-cache coherency operations between CPU cores.

It’s mostly fine, until you run into memory leaks due to circles or because some part of your program holds onto the root of some large shared pointer graph and you have no idea which part. If you take it very far, like some code bases I worked with did, you discover that everything needs to be shared pointer now, because most lifetimes are no longer explicit but implicitly defined by the life time of the shared pointer that holds it.

Reasons I can think of:

- Wrapping all objects in shared pointer is annoying. - If you stick to that convention, you have to do it on every call side, while you only have to implement RAII once. - You can enforce invariants of your class with RAII, that you can't with a plain shared_ptr - Regarding efficiency: It has the overhead of reference counting plus you have to store all objects on the heap instead of the stack. In hot loops this may hurt cache locality.

Most of the time unique-ptr is faster and makes it easier to reason about your program. There is more than heap managemant to performant code and shared ptr makes it harder to reason about those other areas.

Why, we do. Whenever there is data on heap that needs to be shared that is

unique_ptr is much better because then each object has a sole owner, which makes object lifetimes much easier to reason about and you can't end up with cyclic references causing memory leaks.

Author here, I do prefer a language like Rust that makes all of this automatic but that isn't always an option. There are other parts of Rust that can be hard as well.

I wrote this article for a few friends who have recently started working with an existing, large C++ code base. Some industries like the video game industry have also stuck to C++ (they have their reasons).

A good programmer can work within the given constraints to make a useful program — sometimes, one of those constraints is the choice of language.

Once Qt is properly accessible in Rust, I think your claim will be a lot more realistic. This goes for other important C/C++ libraries (e.g. libavcodec, vips/ImageMagick, VTK) without a solid (maintained, documented, etc...) Rust interface.

> This seems like an extremely low bar.

Is it, though? Most mainstream languages fail to support anything resembling RAII, at least as first-class support. Do you actually have an example of a language that does a better job at resource management than C++?

Where are C++ programmers paid better than Rust programmers? I thought Rust salaries are being driven high by all the crypto/fintech companies + scarcity

For one, the compiler and runtime implementation of the language you might happen to use, that that includes Rust.

> stuck with a C++ programmer you need to figure out how to socialize with.

You're obviously trolling, but:

IME Rust attracts the same 'difficult' characters that are also attracted to C++ (because both are 'puzzle solving languages' instead of 'problem solving languages') the typical Rust coder may be even worse because of the missionary fervor and 'holier than thou' attitude.

Modern C++ does give you move semantics, which makes RAII a lot more expressive, especially with smart pointers.

One things about RAII that I find is that, a bit like inheritance, it's actually not something you have actually do nearly as much as the emphasis it gets in the first chapters of all the books implies. How often do you actually write a move constructor or even a destructor in workaday code? Most of it is done for you by the stdlib (unique_ptr, say) or libraries. Of course it needs to be understood, and understood well, but it feels like landing a plane: you have know it well and it's not unusual and certainly not wrong, but also flying is mostly doing things other than landings.

How many modern compilers will let you write import std; in a C++ file and build the executable without shenanigans ? GCC 15 still does not let you compile a C++23 code with:

    g++ -std=c++23 -fmodules foo.cpp

Without manually generating the std module first. Until all compilers will directly accept the import keyword it won't be adopted on a large scale by regular programmers.

> It is a diservice to C++, to paint RAII as modern C++.

I think you're missing context. The term "modern C++" is used to refer to idiomatic C++ introduced in C++11. It has been that way for a couple of decades.

https://learn.microsoft.com/en-us/cpp/cpp/welcome-back-to-cp...

The article touches on the topic of move semantics and move constructors. That's modern c++. That's not your C++98 RAII.

In the same vein, "modern CMake" is also the term used to refer to the declarative style that followed the release of CMake 3, which dates back years.

Author here, what you say is entirely correct — I didn't emphasize enough that this was all possible before in a more limited way. Those parts were cut out to try to make the article more focused on understanding RAII.

The modern parts covered in the article are the move semantics making RAII more expressive and the standard library embracing the concept throughout.

I think the idea of modern is to convince everyone to give these 'new' techniques a try if they aren't already using them.

There’s still a huge part of the industry that writes a mix of C-style C++.

Modern C++ is all about template metaprogramming, concepts, move semantics, ranges, etc.

But there’s a significant cognitive load will all of that.

I used to program a lot in C++ but switched to a number of different programming languages since then. Everything in C++ is this way and it’s hard to understand that things don’t have to be this way when you’re in the trenches of C++.

C++ is a difficult language to use well but it becomes a lot easier when you turn on the 'correct' warnings. Turning on the `-Wdeprecated-copy-dtor` warning would help you not forget one of the cases in the rule of 3.

I would have loved it if this warning was on by default but sadly, you have to know to turn it on.

It is possible, but it isn't hard to remember the rules. The scope of where you can mess up is isolated to the single class so it is generally possible to get this right. Manual memory management is easy when the new and delete are near each other, but you often need them far removed. RAII ensures the places you can mess up are close.

A static analisys tool can enforce the rule as well- you should have one.

unfortunately though this is one area that because c++ predates RAII it can't changethe defaults without breaking a lot of code. I am saying the problem is manageable - there is a real problem though. If you make a new language learn from this mistake.

This is also a problem when an object referenced by a shared_ptr is destroyed much later than expected because some obscure part of the code still holds a reference to the object.

That's why in many situations it makes sense to have an explicitly called discard() method, while the destructor is 'empty' and only checks that discard has actually been called.

Of course that also means that RAII isn't all that useful for such situations.

Author here, I put that in place for people who skim articles or paragraphs — this is a surprising amount of people.

Would it be better if it was more subtle? Were you reading in dark or light mode?

> Kinda wish I had an excuse to write some C++.

I had the same feeling in grad school back ~15 years ago… I could pick any language for my coursework, so I picked C++ purely because it seemed an important language to learn. I was also tracking C++0x (later C++11) very carefully just for academic purposes. I’ve still never used C++ at work but I don’t regret using it in grad school, learning it gives a lot of insight into tradeoffs when designing a language, and I felt it was a lot easier to pick up Rust later on having already known C++.