[xroche]

> C++ was discussed as having too many undesirable characteristics.

I tend to agree, as a C++ developer. There are many core issues in the language that haven't been resolved and that are unacceptable for kernel code.

My personal pet peeve: C++ is unable to reallocate a new[] region. This makes basically all structures (vector, hashmap, trees...) unusable for large data handling.

[kllrnohj]

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.

[xroche]

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

[pjmlp]

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.