Of those structures only vector benefits from realloc anyway. And if you really want it, it's not terribly hard to write. You can static assert that the template type is trivially movable which would make it safe to realloc.

But this is assuming you have a malloc implementation that does something other than implement realloc as just malloc+memcpy+free. Which not many do, not unless the allocation is so large as to be in its own dedicated mmap or similar.

That aside, sure would be great if you elaborated on these unsuitable, unresolved for kernel language issues? Exceptions and rtti are the only two I'm aware of and both have had off switches for decades.

> And if you really want it, it's not terribly hard to write

Sure, but basically it means rewriting all structures that rely on a bucket of stuff.

By the way maps often use a large bucket, and rehash in-place can be preferable.

> Which not many do, not unless the allocation is so large as to be in its own dedicated mmap

Do you know a modern operating system that does not have a mremap equivalent ?

On Linux you pretty much use it as soon as you reach large blocks.

> By the way maps often use a large bucket, and rehash in-place can be preferable.

std::unordered_map (what I'm guessing you meant by a hashmap) uses a linked list for the nodes. There's no movement in the first place to worry about being realloc'd.

> Do you know a modern operating system that does not have a mremap equivalent ?

You have to be very large before most mallocs will put you on a dedicated mmap that can even be mremap'd at all.

If you're working with stonking huge data inline in a std:: vector... Yeah just make a container for that usage, not really an issue. There's tons of examples out there, typically to add SSO but doing realloc would be the same basic thing.

Google (C++17 subset in Zircon), Apple (IO Kit drivers with Embedded C++) and Microsoft (since Vista), ARM (mbed) IBM (C++ as PL/S replacement) think otherwise.