> For anything more demanding it's horrifically bloated and bad

C++ containers are designed for average demands. If you need something more specific, you can always use an alternative implementation. And it's better than messing with macros in pure C.

> you have to deal with RAII

What's problematic with it?

> implicit allocations

Allocations aren't implicit. It's usually clear from the documentation where allocation takes place (like in concatenating strings or copying strings).

> unexpected mutation (invalidation)

It's not the case with standard library containers. Mutating methods aren't const-qualified, so that it's clear where mutation can take place. And in C++ it's strictly recommended to mark as const everything in regular user code which shouldn't be mutated.

▲ jstimpfle 3 hours ago | parent [-]

> C++ containers are designed for average demands. If you need something more specific, you can always use an alternative implementation.

As someone who has been programming exclusively in C/C++ for a long time -- the biggest selling point for these languages in 2026 is exactly being suited to doing something specific, not generic.

> Allocations aren't implicit

    std::map<int,int> m;
    m[1] = 42; // implicit alloc
    auto m2 = m; // implicit too

> in C++ it's strictly recommended to mark as const everything in regular user code which shouldn't be mutated.

Theory and practice. Making everything const correct is too painful in practice, often impossible. It's a trap for bean counters that can't focus on getting some actual useful work done. I'm being harsh to my own past self here. Counter question: why include allocation mechanics with some existing data that never gets changed? Why should we have to add much more boilerplate to get the simpler thing?

▲

Panzerschrek 2 hours ago | parent [-]

> m[1] = 42; // implicit alloc

operator[] of associative containers is mutating and may allocate. It's mentioned in the documentation. And there is no operator[] overloading for const instances, so that you can't trigger an allocation by just reading elements from it.

> auto m2 = m; // implicit too

Taking a copy requires making an allocation. Do you expect some other behavior in such case?

> Making everything const correct is too painful in practice, often impossible

Maybe you are dealing with some legacy codebase (from 90s)? I have worked with multiple codebases in past 10 years or so and keeping things which shouldn't be mutated const wasn't a problem at all. All the code was written using such approach.

> why include allocation mechanics with some existing data that never gets changed

I don't think I fully understand this question. What never gets changed? In your example you are mutating a container and taking a copy of it (which can be changed later).

	▲	jstimpfle 2 hours ago \| parent [-]
		> Do you expect some other behavior in such case? No, just saying this stuff is implicit and thus hard to read. More so the allocation on indexing assignment. and keeping things which shouldn't be mutated const wasn't a problem at all. > and keeping things which shouldn't be mutated const wasn't a problem at all. As soon as datastructures become more complicated and more interconnected, it's not clear anymore what const should even mean (issues are similar as with deep vs shallow copies, how do you even draw the lines, where are the objects?). And the major philosophical flaw in the const vs. non-const distinction is that to make a strict separation you have to move everything mutable into constructor calls (for the most part, not getting more into the weeds of C++). Which is very awkward, it's a real tradeoff you need to be aware of. I realized only after playing these games for a long time what a waste of time it is and how much complexity it creates.