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.
Conversation
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.
1
1
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.
You can use Boost Range to implement algorithms like generalized random access sorting algorithms even though you can't do it in Rust. Range-based iterators are way more ergonomic and I don't think they're any less powerful. It's mostly just the constraints of borrow checking.
1
1
Replying to
Definitely in agreement there. And yeah, Boost has all the boilerplate to simplify defining your own iterators, it's just a shame since std::iterator got you 80% there and was already in the STL.
Replying to
Yeah, this could be doable at least for recursive algorithms if you could split the iterator (which I believe, although correct me if I'm wrong) into non-overlapping segments, which should work for mutable references. Could be useful for implementing a merge sort or the like.