I don't know why people use 'new' and 'delete' in all the examples how memory in C++ works because you never normally use them during coding only if you want to make your own container which you might do once to learn about the internals.
C++ by default creates objects by value (opposed to any other language) and when the variable goes out of scope the variable is cleaned up.
'new' you use when you want to make a global raw pointer outside of the normal memory system is how I would see it. You really never use it normally at least I don't.
People use `new` and `delete` when explaining memory in C++ because those are the language primitives for allocating and releasing memory in C++.
That rule of thumb is only a useful rule if you don't care about how memory works and are comfortable with abstractions like RAII. That's fine for lots of real code but dismissing `new` and `delete` on principle is not interesting or productive for any discussion.
I understand C++ has a lot of operators which are variously reserved but not standardized ("asm") largely obsolete but still needed because of perverse C programmers ("goto") still reserved long after their usefulness subsided ("register") or for ideas that are now abandoned ("synchronized") not to mention all its primitive types ("double", "signed", "long", "short", "char8_t") and redundant non-textual operators given ASCII names like ("and_eq", "bitand", "xor")
But it also has dozens, like new and delete which look like features you'd want. So kinda makes sense to at least mention them in this context.
In production, odds are you are relying on allocators or containers others already wrote. You coming in in 2026 may not ever use the keywords directly, but you'll either be using abstractions that handle that for you (be it STL or something internal) or using some custom allocation call referring to memory already allocated.
But yes, I'd say a more general rule is "allocate with caution".
Such article can end up with a 'false balance' bias by introducing and showing a method one should avoid to motivate the solution. What some people learn is "there are two options".
Maybe it works be better to start with "that's how we do it" and only afterwards following up with "and that's why".
He's making it massively more complex than it actually is
{ // this scope is owner
// allocate
auto my_obj = MyObj{};
// this function scope does not have ownership of my_obj, should take (const MyObj& obj) const reference as parameter
do_something(my_obj);
Are you sure? It seems as though ultimately Microsoft's STL for example ends up calling std::allocator's allocate function which uses the new operator.
Ownership problems with pointer/references don't end with allocation.
A codebase can use only std::make_unique() to allocate heap, and still pass around raw pointers to that memory (std::unique_ptr::get()).
The real problem is data model relying on manual lifetime synchronization, e.g. pass raw pointer to my unique_ptr to another thread, because this thread joins that thread before existing and killing the unique_ptr.
I don’t disagree. That’s why I don’t write C++ anymore. It’s a masochistic language and trying to do it in a team environment with people who do understand how to do it properly is a mess let alone adding in people who don’t know.
Well in interviews this is tricky. Sometimes the interviewer wants to see I can new/delete properly, sometimes this tells me "well, if that's the style they are using I better go elsewhere"
If it's done as part of a "here is legacy code, suggest ways to improve it" question one should point it out, though.
Don’t worry. The question was super basic and almost every candidate still failed to mention that you need to delete in the destructor, that copying requires a new allocation or that you also need to define the move constructor. It made me sad about the state of C++ developers and thankful that Rust makes such mistakes impossible.
many schools (like mine) don't teach unique pointers in the pure "programming" class sequence, but offer a primer in advanced classes where c++ happens to be used, with the intent to teach manual memory management for a clearer transition to e.g. upper-levels which use c.
and that would compile. But it's not a very good idea and you should be able to, well, not do that.
In modern C++, we avoid allocating and deallocating ourselves, as much as possible. But of course, if you jump to arbitrary code, or overwrite something that's due as input for deallocation with the wrong address, or similar shenanigans, then - it could happen.
The trouble with C++ is that it maintains backwards compatibility with C, so every error-prone thing you could do in C, you can still do in C++, even though C++ may have a better way.
The modern, safest, way to use C++, is to use smart pointers rather than raw pointers, which guarantee that nothing gets deleted until there are no more references to it, and that at that point it will get deleted.
Of course raw pointers and new/delete, even malloc/free, all have their uses, and without these low level facilities you wouldn't be able to create better alternatives like smart pointers, but use these at your own peril, and don't blame the language if you mess up, when you could have just done it the safe way!
> which guarantee that nothing gets deleted until there are no more references to it, and that at that point it will get deleted.
To be more precise, C++'s smart pointers will ensure something is live while specific kinds of references the smart pointer knows about are around, but they won't (and can't) catch all references. For example, std::unique_ptr ensures that no other std::unique_ptr will own its object and std::shared_ptr will not delete its object while there are other std::shared_ptrs around that point to the same object, but neither can track things like `std::span`/`std::string_view`/other kinds of references into their object.
> std::unique_ptr ensures that no other std::unique_ptr will own its object
Literally all std::unique_ptr does is wrap the pointer. If we make two unique_ptrs which both think they own object X then not only will they both exist and point at X (so they don't actually ensure they're unique) they'll also both try to destroy X when they disenage e.g. at the end of a scope, leading to a double free or similar.
Uniqueness is a property you are promising, not one they're granting.
I expect you knew this, but it's worth underscoring that there is no magic here. This really is doing only the very simplest thing you could have imagined, it's a pointer but as an object, a "smart pointer" mostly in the same sense that if I add a cheap WiFi chip to this refrigerator and double the price now it's a "smart fridge".
It's really asking for trouble if you view it that way - that you are going to allocate something, then uniquely pass it to a single unique_ptr, or shared_ptr, to manage and release. Better really to use std::make_unique() and std::make_shared().
The smartness, limited though it may be, is just that since it "knows" it's the owner, it knows that it's responsible for releasing it at the appropriate time (reference counted in the case of a shared pointer).
A lot of the value isn't just the automatic release, but that these classes, unique_ptr, and shared_ptr, are built to enforce their semantics, such as literally not being able to copy a unique_ptr, but are able to move it, and copying a shared_ptr being allowed and increasing the reference count of the object.
Yes - they are just simple classes, but using them as intended does avoid a lot of common programmer memory management mistakes, and highly adds to the readability of your program, and ability to reason about ownership, since use of these types rather than raw pointers in effect documents who the owner(s) are, and enforces that this documentation is the reality.
It's an important distinction, just like it's important to know that "const foo *" doesn't mean the foo is constant, just that YOU cannot change it.
Just because you build a unique_ptr from a raw pointer it doesn't mean that it is now magically owned by the object. You also have to ensure that no other place already did that, which unique_ptr simply cannot enforce.
I was just talking about ownership and smart pointers.
C++'s non-owning "view" classes are a different matter, and the issue there isn't ownership but lifetime of the view vs the underlying data the view is referencing (which in case of string_view could be literally anywhere - a local array of char, a malloc'd block of memory, etc!!).
I'm not a fan of a lot of the (relatively) more recent additions to C++. I think C++14 was about the peak! Given that C++ is meant to be usable as a systems programming language, not just for applications, and given that many new features being added to C++ are really library additions, not language ones, then it's important for the language to include unsafe lower level facilities than can be used for things like that, but actually encouraging application developers to use classes like this that are error-prone by design seems questionable!
> but neither can track things like `std::span`/`std::string_view`/other kinds of references into their object.
Sure, and if you get into it there are two issues here.
1) Smart pointers are a leaky abstraction that still gives you access to the underlying raw pointer if you want, with which you can shoot yourself in the foot.
2) It's not the smart pointer's fault, but the type you use them to point to might also be a leaky abstraction (e.g. std::string, which again allows access to the underlying raw pointer), or might just be some hot garbage the developer themselves wrote!
I suppose so, but I think it's relatively rare for languages to just drop support for older features and force developers to rewrite code using newer mechanisms.
Python 2 to 3 is a good example of what can be expected to happen - very slow adoption of the new version since companies may just not have the resources or desire to rewrite existing code that is running without problems.
Late in the C++ 20 timeline P1881 Epochs were proposed. Similar to Rust's editions, which at that time had been tried in anger only once (2018 Edition) this proposed that there should be a way for C++ to evolve, forbidding obsolete syntax in newer projects rather than just growing forever like cancer.
Epochs was given the usual WG21 treatment and that's the end of that. Rust shipped 2021 Edition, and 2024 Edition, and I see no reason to think 2027 Edition won't happen.
The current iteration of Bjarne's "Profiles" idea is in a similar ballpark though it got there via a very different route. This time because it will aid safety to outlaw things that are now considered a bad idea. If this goes anywhere its nearest ship vehicle is C++ 29.
Now, Python 2 to Python 3 did take a few years, maybe a decade. But just shipping the mechanism to reform C++ looks likely to take at least nine years. Not the reform, just the mechanism to enable it.
In general, even though semantic changes haven't yet been a thing in editions so far.
Crate A uses edition X.
Crate B uses edition Y + N, which has broken Rust language semantics between those editions, or changed a standard library type that Crate A uses on its public API in a backwards incompatible way.
Now an application on edition Y + M, with M >= N, would like to depend on Crate A and Crate B, and calling that incompatible API would be a requirement for the implementation goal.
So far editions haven't bothered covering such cases, deemed as not worthwhile thinking about.
Those in such scenarios get to hunt for another crate to replace Crate A, or have a local fork.
I think it would be useful to give an example of the kind of semantics that would be desirable to change, and where people might think that it should be possible to change at an edition boundary.
I’m not very sure, but maybe something like unforgettable types? Or linear types? Maybe negative trait bounds, or specialization?
That was the example, now if you rather want to play defensive instead of engaging into a meaningful discussion about the Rust approach to language versioning and its constraints, well it is as it is.
> Python 2 to 3 is a good example of what can be expected to happen
People keep bringing this up when discussing backwards compatibility breaks, but I think the conclusion should be a bit more nuanced than just "backwards compatibility break <=> years (decades?) of pain".
IMHO, the problem was the backwards compatibility break coupled with the inability to use Python 2 code from 3 and vice versa. This meant that not only did you need to migrate your own code, but you also needed everything you depend on to also support Python 3. This applied in reverse as well - if you as a library developer naively upgraded to Python 3, that left your Python 2 consumers behind.
Obviously the migration story got better over time with improvements to 2to3, six, etc., that allowed a single codebase to work under both Python 2 and 3, but I think the big takeaway here is that backwards compatibility breaks can be made much more friendly as long as upgrades can be performed independently of each other.
Python3 drops support for older versions of python3 all the time. Every single release comes with a bunch of deprecated and removed features. There is a very strong chance that a python 3.7 codebase is totally broken on 3.14. Almost no language takes backwards compatibility as seriously as c++ does.
It's an interesting policy decision for a language - whether to guarantee (or at least practice) ongoing backwards compatibility or not.
The benefit of NOT maintaining backwards compatibility is that hopefully you end up with a cleaner language without all the baggage of the past, and "impedence mismatches" of new features that don't play well with old ones, etc, etc.
However, as a developer, I think I prefer the backwards compatible approach, knowing that:
1) Upgrading to latest version of the compiler hopefully isn't a big deal, and I can take advantage of any benefits that brings, including new language features, without having to sign up for rewriting existing tested code to remove deprecated features. In a large code base any such forced rewrites could be pretty onerous, and may involve a lot of retesting and potential for introducing bugs into code that was previously working.
2) It's nice to be able to take older projects, that you haven't worked on in a while (whether hobby projects, or legacy corporate code) and have the code still compile with the latest installed tool set, rather than to have developed "bit rot" due to using language features that have since been deprecated. Of course bit rot may also occur due to library changes, so language backwards compatibility is no guarantee of smooth sailing.
Maybe going forwards, with AI coding tools, this will become less of an issue, if they become capable of this sort of codebase updates without introducing errors. In fact, going forwards it may well be that choice of programming languages itself becomes seen as more something the tooling takes care of. Nowadays we write in high level languages and don't really think or care about what the generated machine code looks like. Maybe in the future we can write in high level instructions to the AI, without even having to care what the implementation language is?
The modern safest way to use C++ involves lifetime annotations and ownership annotations run under multiple built-in Clang constraint solvers, but this isn't what most users do.
You can also do that intentionally and correctly. After all `delete this;` is a valid statement that can occasionally be useful. That said, I’ve only seen this in old pre-C++11 code that does not adhere to the RAII best practice.
Why are some examples full of errors? The `set_vec` method for instance does not bind the reference, you can't change the reference itself... so the code would simply copy the vector and there would be no dangling reference... And `B` is missing a constructor since the default constructor would be ill-formed (you can't default initialize a reference).
Anyway the article is quite approachable, do not take my criticism to shy away from writing!
Matt Godbolt's tool lets your reader play with your examples and learn more about what's going on. As a bonus, if it doesn't compile and work in Compiler Explorer now you know early before you hit "publish". It's the same reason you should run a spellchecker, raweht thun jstu hope forr th bess
"In Rust you need to worry about borrowing. In C++ you don't have to worry about borrowing; in C++ you have to worry about ownership, which is an old concept..." :-P
C++ doesn’t really have an ownership system. You can use certain language features to implement certain kinds of ownership discipline, but the language itself doesn’t really have an opinion on who should own what. For example, the article talks about cases where a returned value “must” be deallocated by the calling code, but there is no “must” about it as far as the language is concerned. You’re perfectly at liberty to allocate something without ever freeing it (and this isn’t even a memory leak if the value is needed throughout the lifetime of the program).
Does anyone reading this have links to people who have written specifically about a C++ ownership model that rejects the smart_ptr/RAII/friends model in favor of an ownership model that embraces bulk allocations, arenas, freelists, etc? I know there are groups of highly productive programmers that feel the traditional C++ ownership model is hot garbage, and I'd love a resource that puts down specific arguments against it, but I've never come across one myself.
Good one. I was blessed to have the opportunity to watch that one live, on stream. It's always stuck with me and, now that I think about it, is the best resource I know of that puts those ideas into words/writing.
If you have requirements for high performance then the traditional C++ "ownership model" (I would say a better description is "ownership strategy") is definitely "slow". It's pretty "safe" in that you usually aren't going to leak a bunch with it but bull allocations, arenas, and freelists are all potentially faster. And you wouldn't use them if they were slower since they're (usually) more to deal with.
But even in software using these strategies, they probably will be using different ownership strategies in different parts of the code. Once you're writing high performance code, you will use specific strategies that give you the best results. But it's completey domain specific.
What makes you think that RAII- and arena-based strategies are in tension with one another? RAII and smart pointers are more related to the ownership and resource management model. Allocating items in bulk or from arenas is more about where the underlying resources and/or memory come from. These concepts can certainly be used in tandem. What is the substance of the argument that RAII, etc. are "hot garbage?"
The best argument I've ever come across against using RAII is that you end up with these nests of objects pointing to one another, and if something fails, the cleanup code can really only do one thing, which is unwind and deallocate (or whatever the cleanup path is). This structure, generally, precludes the possibility of context dependent resource re-usage on initialization failure, or on deallocation, because you kind of have to have only one deallocation path. Obviously, you could imagine supporting in an RAII context, but, the point is that you probably have to put a fair bit of conscious effort into doing that, whereas if you have a less .. rigid.. ownership model, it becomes completely trivial.
I agree that the allocation model and ownership model are independent concepts. I mentioned arena allocation because the people I know that reject the traditional C++ ownership model generally tend to favor arenas, scratch space, freelists, etc. I'm specifically interested in an ownership model that works with arenas, and tracks ownership of the group of allocations, as opposed to the typical case we think about with RAII where we track ownership of individual allocations.
That "nest of objects point to each other" makes no sense ... RAII is just a technique where you choose to tie resource management to the lifetime of an object (i.e. acquire in constructor, release in destructor).
If an exception gets thrown, causing your RAII object scope to be exited, then no problem - the object destructor gets called and the resource gets released (this is the entire point of RAII - to make resource allocation and deallocation automatic and bullet-proof).
If you are creating spaghetti-like cross-referencing data structures, then that is either poor design or something you are doing deliberately because you need it. In either case, it has nothing to do with RAII, and RAII will work as normal and release resources when the managing object is destroyed (e.g. by going out of scope).
RAII could obviously be used to allocate/free a resource (e.g. temp buffer) from a free list, but is not really relevant to arena allocation unless you are talking about managing the allocation/release of the entire arena. The whole point of an arena allocator is the exact opposite of RAII - you are deliberately disconnecting individual item allocation from release so that you can instead do a more efficient bulk (entire arena) release.
Another commentor succinctly pointed out one argument against RAII+friends is that it encourages thinking about single objects, as opposed to bulk processing.
In many contexts, the common case is in fact bulk processing, and programming things with the assumption that everything is a single, discrete element creates several problems, mostly wrt. performance, but also maintainability. [1][2]
> The whole point of an arena allocator is the exact opposite of RAII
Yes, agreed. And the internet is rife with people yelling about just how great RAII is, but comparatively few people have written specifically about it's failings, and alternatives, which is what I'm asking about today.
I don't think the "complex web of objects to be deallocated" scenario is usually a problem, but I generally agree with your points. As always, careful design and control of the software is important. Abstractions are limited; spend them carefully.
> one argument against RAII+friends is that it encourages thinking about single objects, as opposed to bulk processing.
RAII is just a way to guarantee correctness by tying a resource's lifetime to that of an object, with resource release guaranteed to happen. It is literally just saying that you will manage your resource (a completely abstract concept - doesn't have to be memory) by initializing it in an objects constructor and release it in the destructor.
Use of RAII as a technique is completely orthogonal to what your program is doing. Maybe you have a use for it in a few places, maybe you don't. It's got nothing to do with whether you are doing "bulk procesing" or not, and everything to do with whether you have resources whose usage you want to align to the lifetime of an object (e.g this function will use this file/mutex/buffer, then must release it before it exits).
The alternative to RAII is simply do-it-yourself ! For example, if you are writing multi-threaded code and need a mutex to protect some data structure, then you'd need an explicit mutex_lock() before the access, and an explicit mutex_unlock() afterwards... if your code might throw exceptions or branch due to errors, then make sure that you have mutex_unlock() calls everywhere necessary!
Automating this paired lock and unlock, to avoid any programmer error in missing an unlock in one of the error paths, just makes more sense, and this is all that RAII is doing - it's not some mysterious religion or design philosophy that needs to pervade your program (other than to extent that it would make sense to remove all such potential programmer errors, not just some!).
In this mutex example, RAII would just mean having a class "MutexLocker" (C++ provides std::lock_guard) that does the mutex_lock() in it's constructor and mutex_unlock() in it's destructor.
Without RAII, your code might have looked something like this:
try {
mutex_lock(mut);
// access data structure
mutex_unlock(mut);
} catch (...) { // make sure we unlock the mutex in the error case too !
mutex_unlock(mut);
}
With the RAII approach the mutex unlocks are automatic since they'll happen as soon as the mutex locker goes out of scope and its destructor is called, so the equivalent code would now look like this:
try {
MutexLocker locker(mut);
// access data structure
} catch (...) {
}
That's it - no big deal, but note that now there was no need to add multiple mutex unlock calls in every (normal + error) exit path, and no chance of forgetting to do it.
You can do the same thing anywhere where you want to guarantee that some paired "resource" cleanup activity take place, whether that is unlocking a mutex, or closing a file, or releasing a memory buffer, or whatever.
You may not think of it as RAII, but this approach of automatic cleanup is being used anywhere you have classes that own something then release it when they are done with it, for example things like std::string (and all the C++ container classes) is doing this, as are C++ <stream> file objects, C++ smart pointers, C++ lock_guard for mutexes, etc, etc.
The name "RAII" (resource acquisition is initialization) is IMO a poor name for the technique, since the value is more in the guaranteed, paired, resource release than the acquisition, which was never a problem. Scope-based resource management, or Lifetime-based resource management, would better describe it!
Of course RAII isn't always directly applicable because maybe you need to acquire a resource in one place and release it someplace else entirely, not in same scope, although you could choose to use a smart pointer together with a RAII resource manager to achieve that. For example create a resource with std::make_shared<ResourceManager>() in one place, and resource release will still happen automatically whenever reference counting indicates that all uses of the resource are done.
There are plenty of people who use RAII with arenas for nested group of objects.
Bloomberg for example had a strong focus on that, and they enhanced the allocator model quite significantly to be able to standardize this. This was the reason for stateful allocators, scoped allocators, uses-allocator construction and polymorphic memory resources.
In my library [1], wrapping the CUDA APIs in modern C++, I do allocations which are not exactly from an arena, but something in that neighborhood - memory spaces on context on GPU devices.
Unlike the GP suggests, and like you suggest, I have indeed embraced RAII in the library - generally, not just w.r.t. memory allocation. I have not, however, replicated that idioms of the standard library. So, for example:
* My allocations are never typed.
* The allocation 'primitives' return a memory_region type - essentially a pointer and a size; I discourage the user from manipulating raw pointers.
* Instead of unique_ptr's, I encourage the use of unique_span's: owning, typed, lightweight-ish containers - like a fusion of std::span<T> and std::unique_ptr<T[]> .
Those types of allocation technique were common back in the day for efficiency reasons, maybe still relevant for things like embedded programming where you need to be more careful about memory usage and timing, but I would say that nowadays for normal application usage you are better off using smart pointers.
It's not a matter of one being strictly better than the other, but rather about using the right tool for the job.
I disagree, as group lifetimes are conceptually and architecturally often easier and simpler than having lots of individual lifetimes managed by smart pointers. And sure, you can often slap shared_ptr around the place, or hopefully a less lazy smart ptr choice, but it makes the code harder to understand by obscuring ownership rather than eliminating it as a concern.
I don't understand why you see it that way... Whether using an arena allocator or smart pointer, in both cases you need to allocate the individual object (p = arena_allocate(arena, ...), or p = std::make_unique<T>()). In the case of a smart pointer that is all you have to do - deallocation will be automatic. In the case of the arena allocator you will also need to deallocate the entire arena at the appropriate time.
How are you conceptualizing this that the arena allocator is simpler?
How are you conceptualizing smart pointers as "obscuring" ownership, when the entire point of them is to make ownership explicit! The smart pointer IS the owner!
Such a model likely would not be referred to as "ownership". This is a relatively recent metaphor for memory management that came well after the concepts you mentioned. The fact that such a metaphor is core to rust's memory model is no coincidence.
> explicitly rejects the smart_ptr/RAII/friends model in favor of bulk allocations, arenas, freelists, etc?
These aren't mutually exclusive; you can use the former to manage the latter, after all.
> I know there are groups of highly productive programmers that feel the traditional C++ ownership model is hot garbage
I'm not aware of links off the top of my head, but I can try to summarize the argument.
From my understanding, the argument against RAII/etc. has more to do with the mindset it supposedly encourages more than the concept itself - that RAII and friends makes it easy to think more in terms of individual objects/elements/etc. instead of batches/groups, and as a result programmers tend to follow the easy path which results in less performant/more complex code. By not providing such a feature, so the argument goes, programmers no longer have access to a feature which makes less-efficient programming patterns easy and so batched/grouped management of resources becomes more visible as an alternative.
this article showes very nice what i do not like in modern c++. Packing easy concepts like lifetime and ownership of data behind complex generic named classes. don't get me wrong; i still like OOP, i even use OOP in c (wel OOP like code) but i do not like the concept of packing easy things in complex ones. perhaps im a litte old :)
I don't know why people use 'new' and 'delete' in all the examples how memory in C++ works because you never normally use them during coding only if you want to make your own container which you might do once to learn about the internals.
C++ by default creates objects by value (opposed to any other language) and when the variable goes out of scope the variable is cleaned up.
'new' you use when you want to make a global raw pointer outside of the normal memory system is how I would see it. You really never use it normally at least I don't.
A good rule of thumb is not to use 'new'.
People use `new` and `delete` when explaining memory in C++ because those are the language primitives for allocating and releasing memory in C++.
That rule of thumb is only a useful rule if you don't care about how memory works and are comfortable with abstractions like RAII. That's fine for lots of real code but dismissing `new` and `delete` on principle is not interesting or productive for any discussion.
No the primitives are:
{
} // releasedAlso they're operators.
I understand C++ has a lot of operators which are variously reserved but not standardized ("asm") largely obsolete but still needed because of perverse C programmers ("goto") still reserved long after their usefulness subsided ("register") or for ideas that are now abandoned ("synchronized") not to mention all its primitive types ("double", "signed", "long", "short", "char8_t") and redundant non-textual operators given ASCII names like ("and_eq", "bitand", "xor")
But it also has dozens, like new and delete which look like features you'd want. So kinda makes sense to at least mention them in this context.
I think this got away from me, 'cos clearly part way through I start talking about keywords not operators, whoops.
Yes, and no?
In production, odds are you are relying on allocators or containers others already wrote. You coming in in 2026 may not ever use the keywords directly, but you'll either be using abstractions that handle that for you (be it STL or something internal) or using some custom allocation call referring to memory already allocated.
But yes, I'd say a more general rule is "allocate with caution".
Unfortunately they are all over the place on corporate code.
It just makes for an easily understandable example. I don't think the post is advocating for the use of new/delete over smart pointers.
You need to if you want to create a smart pointer from some class with a private constructor.
> I don't know why people use 'new' and 'delete' in all the examples ...
Why? Because the blog post is titled "Understanding C++ Ownership System".
Such article can end up with a 'false balance' bias by introducing and showing a method one should avoid to motivate the solution. What some people learn is "there are two options".
Maybe it works be better to start with "that's how we do it" and only afterwards following up with "and that's why".
He's making it massively more complex than it actually is
{ // this scope is owner
} // memory is releasedYup, just emplace the object directly into the container, or at worst create it by value and then add it to the container with std::move.
even when you write your own container, you do not use new and delete.
Are you sure? It seems as though ultimately Microsoft's STL for example ends up calling std::allocator's allocate function which uses the new operator.
you would use "operator new" (allocates memory only) not "new" (allocates and constructs, and more if using the new[] variant)
You might use placement new though.
And yet, I interviewed 10 people easily where I was using new and delete in the example code and only one person asked "hey - can we use unique_ptr?".
Ownership problems with pointer/references don't end with allocation.
A codebase can use only std::make_unique() to allocate heap, and still pass around raw pointers to that memory (std::unique_ptr::get()).
The real problem is data model relying on manual lifetime synchronization, e.g. pass raw pointer to my unique_ptr to another thread, because this thread joins that thread before existing and killing the unique_ptr.
I don’t disagree. That’s why I don’t write C++ anymore. It’s a masochistic language and trying to do it in a team environment with people who do understand how to do it properly is a mess let alone adding in people who don’t know.
Well in interviews this is tricky. Sometimes the interviewer wants to see I can new/delete properly, sometimes this tells me "well, if that's the style they are using I better go elsewhere"
If it's done as part of a "here is legacy code, suggest ways to improve it" question one should point it out, though.
Don’t worry. The question was super basic and almost every candidate still failed to mention that you need to delete in the destructor, that copying requires a new allocation or that you also need to define the move constructor. It made me sad about the state of C++ developers and thankful that Rust makes such mistakes impossible.
many schools (like mine) don't teach unique pointers in the pure "programming" class sequence, but offer a primer in advanced classes where c++ happens to be used, with the intent to teach manual memory management for a clearer transition to e.g. upper-levels which use c.
C++: Where you can accidentally deallocate an object that's still in the call stack. (true story)
Well, you can also write:
and that would compile. But it's not a very good idea and you should be able to, well, not do that.In modern C++, we avoid allocating and deallocating ourselves, as much as possible. But of course, if you jump to arbitrary code, or overwrite something that's due as input for deallocation with the wrong address, or similar shenanigans, then - it could happen.
The trouble with C++ is that it maintains backwards compatibility with C, so every error-prone thing you could do in C, you can still do in C++, even though C++ may have a better way.
The modern, safest, way to use C++, is to use smart pointers rather than raw pointers, which guarantee that nothing gets deleted until there are no more references to it, and that at that point it will get deleted.
Of course raw pointers and new/delete, even malloc/free, all have their uses, and without these low level facilities you wouldn't be able to create better alternatives like smart pointers, but use these at your own peril, and don't blame the language if you mess up, when you could have just done it the safe way!
> which guarantee that nothing gets deleted until there are no more references to it, and that at that point it will get deleted.
To be more precise, C++'s smart pointers will ensure something is live while specific kinds of references the smart pointer knows about are around, but they won't (and can't) catch all references. For example, std::unique_ptr ensures that no other std::unique_ptr will own its object and std::shared_ptr will not delete its object while there are other std::shared_ptrs around that point to the same object, but neither can track things like `std::span`/`std::string_view`/other kinds of references into their object.
> std::unique_ptr ensures that no other std::unique_ptr will own its object
Literally all std::unique_ptr does is wrap the pointer. If we make two unique_ptrs which both think they own object X then not only will they both exist and point at X (so they don't actually ensure they're unique) they'll also both try to destroy X when they disenage e.g. at the end of a scope, leading to a double free or similar.
Uniqueness is a property you are promising, not one they're granting.
I expect you knew this, but it's worth underscoring that there is no magic here. This really is doing only the very simplest thing you could have imagined, it's a pointer but as an object, a "smart pointer" mostly in the same sense that if I add a cheap WiFi chip to this refrigerator and double the price now it's a "smart fridge".
It's really asking for trouble if you view it that way - that you are going to allocate something, then uniquely pass it to a single unique_ptr, or shared_ptr, to manage and release. Better really to use std::make_unique() and std::make_shared().
The smartness, limited though it may be, is just that since it "knows" it's the owner, it knows that it's responsible for releasing it at the appropriate time (reference counted in the case of a shared pointer).
A lot of the value isn't just the automatic release, but that these classes, unique_ptr, and shared_ptr, are built to enforce their semantics, such as literally not being able to copy a unique_ptr, but are able to move it, and copying a shared_ptr being allowed and increasing the reference count of the object.
Yes - they are just simple classes, but using them as intended does avoid a lot of common programmer memory management mistakes, and highly adds to the readability of your program, and ability to reason about ownership, since use of these types rather than raw pointers in effect documents who the owner(s) are, and enforces that this documentation is the reality.
It's an important distinction, just like it's important to know that "const foo *" doesn't mean the foo is constant, just that YOU cannot change it.
Just because you build a unique_ptr from a raw pointer it doesn't mean that it is now magically owned by the object. You also have to ensure that no other place already did that, which unique_ptr simply cannot enforce.
Of course, you're right and my attempt to add precision was itself insufficiently precise. Hoisted by my own petard :(
I was just talking about ownership and smart pointers.
C++'s non-owning "view" classes are a different matter, and the issue there isn't ownership but lifetime of the view vs the underlying data the view is referencing (which in case of string_view could be literally anywhere - a local array of char, a malloc'd block of memory, etc!!).
I'm not a fan of a lot of the (relatively) more recent additions to C++. I think C++14 was about the peak! Given that C++ is meant to be usable as a systems programming language, not just for applications, and given that many new features being added to C++ are really library additions, not language ones, then it's important for the language to include unsafe lower level facilities than can be used for things like that, but actually encouraging application developers to use classes like this that are error-prone by design seems questionable!
> I was just talking about ownership and smart pointers.
Sure, I was just clarifying that "references" in the bit I quoted covers specific things and not everything with reference-like behavior.
Sure, I should have been clearer that smart pointers only guarantee not to release things until there are no more SMART POINTER references to them.
As soon as you start mix 'n' matching smart pointers and raw pointers into what they are pointing to, then all bets are off!
> but neither can track things like `std::span`/`std::string_view`/other kinds of references into their object.
Sure, and if you get into it there are two issues here.
1) Smart pointers are a leaky abstraction that still gives you access to the underlying raw pointer if you want, with which you can shoot yourself in the foot.
2) It's not the smart pointer's fault, but the type you use them to point to might also be a leaky abstraction (e.g. std::string, which again allows access to the underlying raw pointer), or might just be some hot garbage the developer themselves wrote!
The trouble with C++ is that it maintains backward compatibility with C++.
I suppose so, but I think it's relatively rare for languages to just drop support for older features and force developers to rewrite code using newer mechanisms.
Python 2 to 3 is a good example of what can be expected to happen - very slow adoption of the new version since companies may just not have the resources or desire to rewrite existing code that is running without problems.
Late in the C++ 20 timeline P1881 Epochs were proposed. Similar to Rust's editions, which at that time had been tried in anger only once (2018 Edition) this proposed that there should be a way for C++ to evolve, forbidding obsolete syntax in newer projects rather than just growing forever like cancer.
Epochs was given the usual WG21 treatment and that's the end of that. Rust shipped 2021 Edition, and 2024 Edition, and I see no reason to think 2027 Edition won't happen.
The current iteration of Bjarne's "Profiles" idea is in a similar ballpark though it got there via a very different route. This time because it will aid safety to outlaw things that are now considered a bad idea. If this goes anywhere its nearest ship vehicle is C++ 29.
Now, Python 2 to Python 3 did take a few years, maybe a decade. But just shipping the mechanism to reform C++ looks likely to take at least nine years. Not the reform, just the mechanism to enable it.
Meanwhile editions still don't have an answer for semantics changes exposed on public APIs for crates, each compiled on its own edition.
So what does the compiler chose, the edition of the caller, or the caller?
I don't understand the question, maybe you have an example?
In general, even though semantic changes haven't yet been a thing in editions so far.
Crate A uses edition X.
Crate B uses edition Y + N, which has broken Rust language semantics between those editions, or changed a standard library type that Crate A uses on its public API in a backwards incompatible way.
Now an application on edition Y + M, with M >= N, would like to depend on Crate A and Crate B, and calling that incompatible API would be a requirement for the implementation goal.
So far editions haven't bothered covering such cases, deemed as not worthwhile thinking about.
Those in such scenarios get to hunt for another crate to replace Crate A, or have a local fork.
I think it would be useful to give an example of the kind of semantics that would be desirable to change, and where people might think that it should be possible to change at an edition boundary.
I’m not very sure, but maybe something like unforgettable types? Or linear types? Maybe negative trait bounds, or specialization?
OK, so you don't have any examples, I recommend coming back once you have an example as otherwise there's nothing concrete to engage with here.
That was the example, now if you rather want to play defensive instead of engaging into a meaningful discussion about the Rust approach to language versioning and its constraints, well it is as it is.
> Python 2 to 3 is a good example of what can be expected to happen
People keep bringing this up when discussing backwards compatibility breaks, but I think the conclusion should be a bit more nuanced than just "backwards compatibility break <=> years (decades?) of pain".
IMHO, the problem was the backwards compatibility break coupled with the inability to use Python 2 code from 3 and vice versa. This meant that not only did you need to migrate your own code, but you also needed everything you depend on to also support Python 3. This applied in reverse as well - if you as a library developer naively upgraded to Python 3, that left your Python 2 consumers behind.
Obviously the migration story got better over time with improvements to 2to3, six, etc., that allowed a single codebase to work under both Python 2 and 3, but I think the big takeaway here is that backwards compatibility breaks can be made much more friendly as long as upgrades can be performed independently of each other.
Python3 drops support for older versions of python3 all the time. Every single release comes with a bunch of deprecated and removed features. There is a very strong chance that a python 3.7 codebase is totally broken on 3.14. Almost no language takes backwards compatibility as seriously as c++ does.
It's an interesting policy decision for a language - whether to guarantee (or at least practice) ongoing backwards compatibility or not.
The benefit of NOT maintaining backwards compatibility is that hopefully you end up with a cleaner language without all the baggage of the past, and "impedence mismatches" of new features that don't play well with old ones, etc, etc.
However, as a developer, I think I prefer the backwards compatible approach, knowing that:
1) Upgrading to latest version of the compiler hopefully isn't a big deal, and I can take advantage of any benefits that brings, including new language features, without having to sign up for rewriting existing tested code to remove deprecated features. In a large code base any such forced rewrites could be pretty onerous, and may involve a lot of retesting and potential for introducing bugs into code that was previously working.
2) It's nice to be able to take older projects, that you haven't worked on in a while (whether hobby projects, or legacy corporate code) and have the code still compile with the latest installed tool set, rather than to have developed "bit rot" due to using language features that have since been deprecated. Of course bit rot may also occur due to library changes, so language backwards compatibility is no guarantee of smooth sailing.
Maybe going forwards, with AI coding tools, this will become less of an issue, if they become capable of this sort of codebase updates without introducing errors. In fact, going forwards it may well be that choice of programming languages itself becomes seen as more something the tooling takes care of. Nowadays we write in high level languages and don't really think or care about what the generated machine code looks like. Maybe in the future we can write in high level instructions to the AI, without even having to care what the implementation language is?
The modern safest way to use C++ involves lifetime annotations and ownership annotations run under multiple built-in Clang constraint solvers, but this isn't what most users do.
You can also do that intentionally and correctly. After all `delete this;` is a valid statement that can occasionally be useful. That said, I’ve only seen this in old pre-C++11 code that does not adhere to the RAII best practice.
Why are some examples full of errors? The `set_vec` method for instance does not bind the reference, you can't change the reference itself... so the code would simply copy the vector and there would be no dangling reference... And `B` is missing a constructor since the default constructor would be ill-formed (you can't default initialize a reference).
Anyway the article is quite approachable, do not take my criticism to shy away from writing!
I strongly encourage people writing textual examples in 2026 to use Compiler Explorer.
https://cpp.godbolt.org/
Matt Godbolt's tool lets your reader play with your examples and learn more about what's going on. As a bonus, if it doesn't compile and work in Compiler Explorer now you know early before you hit "publish". It's the same reason you should run a spellchecker, raweht thun jstu hope forr th bess
Yeah, that example's totally wrong, as you say, the std::vector<int> would get copied by value, so there'd be no issue at all.
The title reminds of this:
https://youtu.be/TGfQu0bQTKc?si=7TiDRic6LaWI1Xpc&t=70
"In Rust you need to worry about borrowing. In C++ you don't have to worry about borrowing; in C++ you have to worry about ownership, which is an old concept..." :-P
C++ doesn’t really have an ownership system. You can use certain language features to implement certain kinds of ownership discipline, but the language itself doesn’t really have an opinion on who should own what. For example, the article talks about cases where a returned value “must” be deallocated by the calling code, but there is no “must” about it as far as the language is concerned. You’re perfectly at liberty to allocate something without ever freeing it (and this isn’t even a memory leak if the value is needed throughout the lifetime of the program).
Does anyone reading this have links to people who have written specifically about a C++ ownership model that rejects the smart_ptr/RAII/friends model in favor of an ownership model that embraces bulk allocations, arenas, freelists, etc? I know there are groups of highly productive programmers that feel the traditional C++ ownership model is hot garbage, and I'd love a resource that puts down specific arguments against it, but I've never come across one myself.
Edit: clarity
I'm interested in the same! There are plenty of resources for C[1][2]. I just looked into my old notes and found a post for C++[3].
[1] https://btmc.substack.com/p/memory-unsafety-is-an-attitude-p...
[2] https://www.gingerbill.org/series/memory-allocation-strategi...
[3] https://dmitrysoshnikov.com/compilers/writing-a-pool-allocat...
Nice, thanks. I haven't read those gingerbill ones, I'll take a look :D
Yes: https://m.youtube.com/watch?v=xt1KNDmOYqA
Title: “ Casey Muratori | Smart-Pointers, RAII, ZII? Becoming an N+2 programmer”
Good one. I was blessed to have the opportunity to watch that one live, on stream. It's always stuck with me and, now that I think about it, is the best resource I know of that puts those ideas into words/writing.
If you have requirements for high performance then the traditional C++ "ownership model" (I would say a better description is "ownership strategy") is definitely "slow". It's pretty "safe" in that you usually aren't going to leak a bunch with it but bull allocations, arenas, and freelists are all potentially faster. And you wouldn't use them if they were slower since they're (usually) more to deal with.
But even in software using these strategies, they probably will be using different ownership strategies in different parts of the code. Once you're writing high performance code, you will use specific strategies that give you the best results. But it's completey domain specific.
What makes you think that RAII- and arena-based strategies are in tension with one another? RAII and smart pointers are more related to the ownership and resource management model. Allocating items in bulk or from arenas is more about where the underlying resources and/or memory come from. These concepts can certainly be used in tandem. What is the substance of the argument that RAII, etc. are "hot garbage?"
In reverse order they were asked ..
The best argument I've ever come across against using RAII is that you end up with these nests of objects pointing to one another, and if something fails, the cleanup code can really only do one thing, which is unwind and deallocate (or whatever the cleanup path is). This structure, generally, precludes the possibility of context dependent resource re-usage on initialization failure, or on deallocation, because you kind of have to have only one deallocation path. Obviously, you could imagine supporting in an RAII context, but, the point is that you probably have to put a fair bit of conscious effort into doing that, whereas if you have a less .. rigid.. ownership model, it becomes completely trivial.
I agree that the allocation model and ownership model are independent concepts. I mentioned arena allocation because the people I know that reject the traditional C++ ownership model generally tend to favor arenas, scratch space, freelists, etc. I'm specifically interested in an ownership model that works with arenas, and tracks ownership of the group of allocations, as opposed to the typical case we think about with RAII where we track ownership of individual allocations.
That "nest of objects point to each other" makes no sense ... RAII is just a technique where you choose to tie resource management to the lifetime of an object (i.e. acquire in constructor, release in destructor).
If an exception gets thrown, causing your RAII object scope to be exited, then no problem - the object destructor gets called and the resource gets released (this is the entire point of RAII - to make resource allocation and deallocation automatic and bullet-proof).
If you are creating spaghetti-like cross-referencing data structures, then that is either poor design or something you are doing deliberately because you need it. In either case, it has nothing to do with RAII, and RAII will work as normal and release resources when the managing object is destroyed (e.g. by going out of scope).
RAII could obviously be used to allocate/free a resource (e.g. temp buffer) from a free list, but is not really relevant to arena allocation unless you are talking about managing the allocation/release of the entire arena. The whole point of an arena allocator is the exact opposite of RAII - you are deliberately disconnecting individual item allocation from release so that you can instead do a more efficient bulk (entire arena) release.
Another commentor succinctly pointed out one argument against RAII+friends is that it encourages thinking about single objects, as opposed to bulk processing.
In many contexts, the common case is in fact bulk processing, and programming things with the assumption that everything is a single, discrete element creates several problems, mostly wrt. performance, but also maintainability. [1][2]
> The whole point of an arena allocator is the exact opposite of RAII
Yes, agreed. And the internet is rife with people yelling about just how great RAII is, but comparatively few people have written specifically about it's failings, and alternatives, which is what I'm asking about today.
[1] https://www.youtube.com/watch?v=tD5NrevFtbU
[2] https://www.youtube.com/watch?v=rX0ItVEVjHc&t=2252
I don't think the "complex web of objects to be deallocated" scenario is usually a problem, but I generally agree with your points. As always, careful design and control of the software is important. Abstractions are limited; spend them carefully.
> one argument against RAII+friends is that it encourages thinking about single objects, as opposed to bulk processing.
RAII is just a way to guarantee correctness by tying a resource's lifetime to that of an object, with resource release guaranteed to happen. It is literally just saying that you will manage your resource (a completely abstract concept - doesn't have to be memory) by initializing it in an objects constructor and release it in the destructor.
Use of RAII as a technique is completely orthogonal to what your program is doing. Maybe you have a use for it in a few places, maybe you don't. It's got nothing to do with whether you are doing "bulk procesing" or not, and everything to do with whether you have resources whose usage you want to align to the lifetime of an object (e.g this function will use this file/mutex/buffer, then must release it before it exits).
The alternative to RAII is simply do-it-yourself ! For example, if you are writing multi-threaded code and need a mutex to protect some data structure, then you'd need an explicit mutex_lock() before the access, and an explicit mutex_unlock() afterwards... if your code might throw exceptions or branch due to errors, then make sure that you have mutex_unlock() calls everywhere necessary!
Automating this paired lock and unlock, to avoid any programmer error in missing an unlock in one of the error paths, just makes more sense, and this is all that RAII is doing - it's not some mysterious religion or design philosophy that needs to pervade your program (other than to extent that it would make sense to remove all such potential programmer errors, not just some!).
In this mutex example, RAII would just mean having a class "MutexLocker" (C++ provides std::lock_guard) that does the mutex_lock() in it's constructor and mutex_unlock() in it's destructor.
Without RAII, your code might have looked something like this:
try {
} catch (...) { // make sure we unlock the mutex in the error case too ! }With the RAII approach the mutex unlocks are automatic since they'll happen as soon as the mutex locker goes out of scope and its destructor is called, so the equivalent code would now look like this:
try {
} catch (...) {}
That's it - no big deal, but note that now there was no need to add multiple mutex unlock calls in every (normal + error) exit path, and no chance of forgetting to do it.
You can do the same thing anywhere where you want to guarantee that some paired "resource" cleanup activity take place, whether that is unlocking a mutex, or closing a file, or releasing a memory buffer, or whatever.
You may not think of it as RAII, but this approach of automatic cleanup is being used anywhere you have classes that own something then release it when they are done with it, for example things like std::string (and all the C++ container classes) is doing this, as are C++ <stream> file objects, C++ smart pointers, C++ lock_guard for mutexes, etc, etc.
The name "RAII" (resource acquisition is initialization) is IMO a poor name for the technique, since the value is more in the guaranteed, paired, resource release than the acquisition, which was never a problem. Scope-based resource management, or Lifetime-based resource management, would better describe it!
Of course RAII isn't always directly applicable because maybe you need to acquire a resource in one place and release it someplace else entirely, not in same scope, although you could choose to use a smart pointer together with a RAII resource manager to achieve that. For example create a resource with std::make_shared<ResourceManager>() in one place, and resource release will still happen automatically whenever reference counting indicates that all uses of the resource are done.
There are plenty of people who use RAII with arenas for nested group of objects.
Bloomberg for example had a strong focus on that, and they enhanced the allocator model quite significantly to be able to standardize this. This was the reason for stateful allocators, scoped allocators, uses-allocator construction and polymorphic memory resources.
In my library [1], wrapping the CUDA APIs in modern C++, I do allocations which are not exactly from an arena, but something in that neighborhood - memory spaces on context on GPU devices.
Unlike the GP suggests, and like you suggest, I have indeed embraced RAII in the library - generally, not just w.r.t. memory allocation. I have not, however, replicated that idioms of the standard library. So, for example:
* My allocations are never typed.
* The allocation 'primitives' return a memory_region type - essentially a pointer and a size; I discourage the user from manipulating raw pointers.
* Instead of unique_ptr's, I encourage the use of unique_span's: owning, typed, lightweight-ish containers - like a fusion of std::span<T> and std::unique_ptr<T[]> .
I wonder if that might seem less annoying to GP.
---
[1] : https://github.com/eyalroz/cuda-api-wrappers/
Those types of allocation technique were common back in the day for efficiency reasons, maybe still relevant for things like embedded programming where you need to be more careful about memory usage and timing, but I would say that nowadays for normal application usage you are better off using smart pointers.
It's not a matter of one being strictly better than the other, but rather about using the right tool for the job.
Many soft-realtime systems make use of these techniques, specifically 3D graphics and game engines.
I disagree, as group lifetimes are conceptually and architecturally often easier and simpler than having lots of individual lifetimes managed by smart pointers. And sure, you can often slap shared_ptr around the place, or hopefully a less lazy smart ptr choice, but it makes the code harder to understand by obscuring ownership rather than eliminating it as a concern.
I don't understand why you see it that way... Whether using an arena allocator or smart pointer, in both cases you need to allocate the individual object (p = arena_allocate(arena, ...), or p = std::make_unique<T>()). In the case of a smart pointer that is all you have to do - deallocation will be automatic. In the case of the arena allocator you will also need to deallocate the entire arena at the appropriate time.
How are you conceptualizing this that the arena allocator is simpler?
How are you conceptualizing smart pointers as "obscuring" ownership, when the entire point of them is to make ownership explicit! The smart pointer IS the owner!
May be interested in https://floooh.github.io/2018/06/17/handles-vs-pointers.html
This is exactly the kind of thing I was after, thank you!
Such a model likely would not be referred to as "ownership". This is a relatively recent metaphor for memory management that came well after the concepts you mentioned. The fact that such a metaphor is core to rust's memory model is no coincidence.
> explicitly rejects the smart_ptr/RAII/friends model in favor of bulk allocations, arenas, freelists, etc?
These aren't mutually exclusive; you can use the former to manage the latter, after all.
> I know there are groups of highly productive programmers that feel the traditional C++ ownership model is hot garbage
I'm not aware of links off the top of my head, but I can try to summarize the argument.
From my understanding, the argument against RAII/etc. has more to do with the mindset it supposedly encourages more than the concept itself - that RAII and friends makes it easy to think more in terms of individual objects/elements/etc. instead of batches/groups, and as a result programmers tend to follow the easy path which results in less performant/more complex code. By not providing such a feature, so the argument goes, programmers no longer have access to a feature which makes less-efficient programming patterns easy and so batched/grouped management of resources becomes more visible as an alternative.
Agreed. I guess I'm interested in anyone that's specifically written about ownership strategies that lean into the group allocation thing.
I think in the `Move` section the delete[] should be delete[] old_buffer; rather than new_buffer;
Why there is the calling of "read(buffer.get());" in the first example (inside of the 'while' loop)?
It is a 'char *buffer' type, unless I'm mistaken raw pointers don't have methods/member functions?
copy-paste error given the next example uses a smart ptr type that has a .get() to get the actual pointer.
this article showes very nice what i do not like in modern c++. Packing easy concepts like lifetime and ownership of data behind complex generic named classes. don't get me wrong; i still like OOP, i even use OOP in c (wel OOP like code) but i do not like the concept of packing easy things in complex ones. perhaps im a litte old :)
Author currently unemployed type post to state in zoomerspeech