6 ms·

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 o

by jesse__ 9mo ago

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

rubymamis 9mo ago
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-problem https://btmc.substack.com/p/memory-unsafety-is-an-attitude-p... [2] https://www.gingerbill.org/series/memory-allocation-strategies/ https://www.gingerbill.org/series/memory-allocation-strategi... [3] https://dmitrysoshnikov.com/compilers/writing-a-pool-allocator/ https://dmitrysoshnikov.com/compilers/writing-a-pool-allocat...
- jesse__ 9mo ago
  Nice, thanks. I haven't read those gingerbill ones, I'll take a look :D
otherjason 9mo ago
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?"
- einpoklum 9mo ago
  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/ https://github.com/eyalroz/cuda-api-wrappers/
- jesse__ 9mo ago
  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.
  - HarHarVeryFunny 9mo ago
    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.
aw1621107 9mo ago
> 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.
- jesse__ 9mo ago
  Agreed. I guess I'm interested in anyone that's specifically written about ownership strategies that lean into the group allocation thing.
nwlieb 9mo ago
Yes: https://m.youtube.com/watch?v=xt1KNDmOYqA https://m.youtube.com/watch?v=xt1KNDmOYqA Title: “ Casey Muratori | Smart-Pointers, RAII, ZII? Becoming an N+2 programmer”
- jesse__ 9mo ago
  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.
verall 9mo ago
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.
GrowingSideways 9mo ago
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.
HarHarVeryFunny 9mo ago
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.
- jesse__ 9mo ago
  Many soft-realtime systems make use of these techniques, specifically 3D graphics and game engines.
- dundarious 9mo ago
  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.
  - HarHarVeryFunny 9mo ago
    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!
edflsafoiewq 9mo ago
May be interested in https://floooh.github.io/2018/06/17/handles-vs-pointers.html https://floooh.github.io/2018/06/17/handles-vs-pointers.html
- jesse__ 9mo ago
  This is exactly the kind of thing I was after, thank you!

by jesse__ 9mo ago

rubymamis 9mo ago

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-problem https://btmc.substack.com/p/memory-unsafety-is-an-attitude-p... [2] https://www.gingerbill.org/series/memory-allocation-strategies/ https://www.gingerbill.org/series/memory-allocation-strategi... [3] https://dmitrysoshnikov.com/compilers/writing-a-pool-allocator/ https://dmitrysoshnikov.com/compilers/writing-a-pool-allocat...

jesse__ 9mo ago
Nice, thanks. I haven't read those gingerbill ones, I'll take a look :D

otherjason 9mo ago

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?"

einpoklum 9mo ago
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/ https://github.com/eyalroz/cuda-api-wrappers/
jesse__ 9mo ago
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.
- HarHarVeryFunny 9mo ago
  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.

aw1621107 9mo ago

> 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.

jesse__ 9mo ago
Agreed. I guess I'm interested in anyone that's specifically written about ownership strategies that lean into the group allocation thing.

nwlieb 9mo ago

Yes: https://m.youtube.com/watch?v=xt1KNDmOYqA https://m.youtube.com/watch?v=xt1KNDmOYqA Title: “ Casey Muratori | Smart-Pointers, RAII, ZII? Becoming an N+2 programmer”

jesse__ 9mo ago
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.

verall 9mo ago

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.

GrowingSideways 9mo ago

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.

HarHarVeryFunny 9mo ago

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.

jesse__ 9mo ago
Many soft-realtime systems make use of these techniques, specifically 3D graphics and game engines.
dundarious 9mo ago
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.
- HarHarVeryFunny 9mo ago
  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!

edflsafoiewq 9mo ago

May be interested in https://floooh.github.io/2018/06/17/handles-vs-pointers.html https://floooh.github.io/2018/06/17/handles-vs-pointers.html

jesse__ 9mo ago
This is exactly the kind of thing I was after, thank you!