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.
1
1
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
Replying to
I implemented Rust's initial iterator support and it was supposed to have random access iterators. However, it didn't fit well into the memory model. For example, it wouldn't be able to work with mutable references so you couldn't use it to implement an algorithm like sorting.
Replying to
Yeah, I understand why. It just makes a lot of algorithm design require more boilerplate or become container-specific, when with C++ a fairly simple abstraction leads to a powerful, generalizable model.
2
Replying to
I did implement RandomAccessIterator for Rust, but it would have only been usable for read-only algorithms like binary search, and other parts of the API like ExactSizeIterator hadn't matured yet. It's really way less useful when you can't use it for mutable references though.
2
1
Show replies