These are not very good arguments and Casey Muratori is hugely biased against RAII and C++ techniques for some reason, probably familiarity with C.
He thinks that every RAII variable is a failure point and that you only have to think about ownership if you are using RAII, so it incurs mental overhead.
The reality is that you have to understand the lifetime and ownership of your allocations no matter what. If the language does nothing for you the allocation will still have a lifetime and a place where the memory is deallocated.
He also talks about combining multiple allocations in to a single allocation that then gets split into multiple pointers, but that could easily be done in C++.
> He also talks about combining multiple allocations in to a single allocation that then gets split into multiple pointers, but that could easily be done in C++.
But this is explicitly the opposite of how the language is designed to be used, because that's the whole point of RAII.
But this is explicitly the opposite of how the language is designed to be used, because that's the whole point of RAII.
Says who? If they all have the same lifetime multiple allocations can be combined into one allocation and deallocation. I've done it before, it makes perfect sense, although I would say it is a somewhat niche optimization.
It's only a “somewhat niche optimization” because the language emphasizes RAII.
There are other ways of writing code—which other languages can incentivize by being designed differently—where it is not a niche optimization, but rather the default.
No, it's an uncommon optimization because if you want speed you avoid memory allocations anyway, hopefully to the point that they have almost no impact.
Heap allocations can be done about 10 million times a second on one core, once you get them out of your loops they should make almost no impact, so grouping a few together when they are only being done once is rare and probably indicative of painting yourself into a corner where something inside a call stack inside hot loop still has to heap allocate.
The other reason is that most heap allocation is for lots of memory that will hold the same type. Manually grouping a bunch of allocations implies that you have multiple different types of arrays all buried inside a hot loop to the extent that you are trying to shave off whatever you can but can't lift those allocations out of the loop.
It basically implies that the optimization has to come without too many changes, because if you could do whatever you want they wouldn't be in the loop in the first place. For these reasons it is a half measure in a niche scenario.
There are other ways of writing code—which other languages can incentivize by being designed differently—where it is not a niche optimization, but rather the default.
This is completely abstract, can you show me exactly what you mean and why it can't be done easily in C++ or with RAII ? It sounds like rationalizing a situation you don't want to be in in the first place.
He thinks that every RAII variable is a failure point and that you only have to think about ownership if you are using RAII, so it incurs mental overhead.
The reality is that you have to understand the lifetime and ownership of your allocations no matter what. If the language does nothing for you the allocation will still have a lifetime and a place where the memory is deallocated.
He also talks about combining multiple allocations in to a single allocation that then gets split into multiple pointers, but that could easily be done in C++.