logoalt Hacker News

Panzerschrek • today at 4:56 PM • 1 reply • view on HN

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

Replies

jstimpfle • today at 5:12 PM

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

➕ show 1 reply