Hacker News Reader

Comment by pjmlp | Hacker News Reader

Strings, something that C still doesn't do properly, not even having something like SDS into the standard library.

<map> does the work just fine, not everyone has winning microbenchmarks as part of their daily work.

Many of the big C++ projects I've worked with have custom string types since the standard one was defficient for some reason or another.

Exactly, and a simple usable string type is just a struct MyString { char *buf; size_t len; }; away. Actual magic is in how you use it, where you allocate it, how you integrate allocation and formatting and logging and I/O... i.e. all the things that aren't solved by crufty complex std::string either.

So simple, and yet most C projects never do it.

Plain C strings all over the place.

Since I learnt C in 1990, knowing to count up to 10 is enough, for the amount of times I saw it actually being done.

The projects and people I follow do this all the time. Just like putting a size field near each regular non sentinel terminated array is useful. But if not doing it (maybe linux kernel in many cases), no big deal either, don't sweat the small stuff. String slices are small and rarely perf critical.

And yet zillion ways better than C strings, which was the point.

> <map> does the work just fine

It has a rather weird interface, at least until C++ 17 when some of the deficiencies were patched somewhat.

It's a slow generic data structure with an unintuitive API. You can use it for leetcode or for CRUD. For anything more demanding it's horrifically bloated and bad. std::string too. Whenever you see STL datatypes like even string and map, you have to deal with RAII, implicit allocations, weird operator syntax, unexpected mutation (invalidation) and so on.

(Spporting or even encouraging destructive mutation, and by this I mean not incrementing counters or anything harmless but allowing iterator invalidations and crashes, are also why std::vector is bad in my opinion, these are idiomatic APIs for 90s and 2000s programming, which we should know better to avoid in 2026).

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

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

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

  > auto m2 = m; // implicit too
  Taking a copy requires making an allocation.

C++ makes it “look nice” at the cost of clarity. But not consistently. Overall, despite addition of syntax sugar in various places to make things look smooth, we arguably have “a lot of syntax” (“syntax castles”) in C++, as a result of embracing a lot of complexity. C, OTOH, avoids both sugar and castles.

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

Great that setjmp/longjmp is explicit, and that in C there are even more liberties to cast away const than in C++, while some surprises in embedded, when the compiler decides const could have been placed into read only memory.

Placing data in .rodata (read only memory) is an actual useful application of const keyword. Not specific to embedded. Arguably there shouldn't have been multiple slightly different meanings of the keyword like that.

I don't know why you are now jumping to setjmp/longjmp, trying to make a point that somehow C is the worst programming languages ever, when all I am trying to argue is for sane programming practices, hinting that more complex features (line especially found in newer languages) are not solutions but part of the complexity problem.

> you have to deal with RAII

If you find that RAII is a problem, I pity how poor a programmer you must be...

You must be very experienced to be so judgemental! But maybe ask the many billions of voxels that get tested per second on my multithreaded and SIMD'ed cutting simulation.

C++ is the best language to write multi-architecture SIMD without relying on compiler magics like autovectorization. It gives you enough tools to define zero-cost abstractions to make SIMD nice.

Yeah... There are libraries like Google Highway but that seems to me like a bulky software abstraction layer even if it is a so-called "zero cost" abstraction. Maybe appropriate in some cases. In my case, I've implemented a couple of lines for AVX2 and AVX512, maybe around 100 lines for the most perf sensitive sections currently, not a big deal. The actual work is in the understanding of the problem and of the phyiscal hardware, and in the software architecture and data layout to even enable vectorized stream processing in the first place. I'm not concerned writing a couple of perf sensitive lines against 2-3 most important concrete vector ISAs. I also fancy adding a GPU backend later (requires D3D12/SM6.0 API level), Highway couldn't help with that.

RAII is terrible for memory resources - it's ok for things like locks I guess. Rarely do I want to couple initialization with allocation, I want bulk allocations/deallocations (and I want precise control over when that happens) and reset()-like functions so I can easily reuse memory.

It couples things and complicates things. Which creates friction against when refactoring a software architecture, making it harder to scale it up.

Fully agree, for locks or other simple begin/end pairs it doesn't create the same kind of architectural damage. But I don't use it even there, because RAII fundamentally doesn't play well with manual cleanup code. It's kind of an all-in game, if you use some RAII there are strong forces (whenever you need to get the "nesting" right) to convert all remaining manual begin/end type code to types that define that functionality out-of-line in the destructor/destructor, leading to fragmentation.

At least is there in the standard library, one doesn't need to invent one from scratch in every single project, or reach out to the tools floppy while not telling the employer due to code ownership.

No need to invent when you already know how it works.

I could re-type all the essential stuff from std::string that I've ever used myself within 10 minutes, no problem, without looking up external sources, including copy & move semantics and whatnot. But I'm deliberately not doing it. Because I don't like this "invention".

Reply on news.ycombinator.com