The low-level C++ dynamic memory allocation API is ridiculously bloated:
en.cppreference.com/w/cpp/memory/n
A global allocator has 8 variants of operator new to implement and 12 for operator delete. In total, there are 22 variants of operator new and 26 for operator delete (4 more soon).
Conversation
It doesn't even offer any form of reallocation, let alone good control over it. The useless std::nothrow_t variants of delete for symmetry with new are a bit funny. They didn't end up adding those for sized allocation as initially planned, so at least they avoided 4 more deletes.
1
2
The configurable hook added in C++11 for freeing memory and triggering a retry at the allocator layer is neat, but real world programs would want to do it at the malloc layer. It only makes sense at this layer if it was a different allocator, which would make very little sense...
1
2
Replying to
Reallocation would be so nice, but we'd have to get guarantees that non-POD classes are relocatable in memory, right?
Right now, most classes can be memcpy-ed to a new location (just no destructors on old), but only guarantees are made for is_trivially_copyable.
1
From what I remember, you're basically safe as long as the class doesn't have a pointer to in-class data, or is virtual (since despite every compiler using a vtable, the implementation is never specified). But still... realllocation without relocatable data is... tricky.
1
Replying to
It could fully support it for these low-level replaceable functions, since it doesn't have types. There could be a variant that's allowed to relocate along with a variant that's not allowed to do that. It could then be used when possible by higher-level APIs if it existed here.
2
1
I don't consider C++ worth improving but they certainly could have wired up the infrastructure for more efficient reallocation. It's pretty sad that std::vector can't do proper reallocation under the hood when the types can support it because infrastructure for it isn't present.
I don't feel it's worth trying to improve C++ at this point though. It's too much of a bloated disaster and doesn't serve the purpose of providing a shared compatible ABI and runtime like C. Extending the malloc API would be useful in the long term but this thing is a lost cause.
1
1
Replying to
On one hand, I agree. On another, I really, really like certain aspects of the language in isolation. The iterator model is great for some algorithms, especially for randomized or recursive algorithms (something say, Rust, lacks).
1
Show replies