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