Comment by TazeTSchnitzel | Hacker News Reader

Comment by TazeTSchnitzel | Hacker News Reader

I feel like every sufficiently large C project ends up reimplementing the same things: binary-safe (or at least explicit-length) strings, dynamically-sized arrays, hashmaps, a set of typedefs for integers and booleans (if the project predates wide C99 support), a macro to count the number of elements in an array, bit manipulation functions, locale-independent string functions…

It's a sad story about the state of the C standard library.

When I see nice C libraries, it does make me want to write new C code. But then I am reminded of the many non-library problems with C, like the `uint64_t m = 1 << n;` footgun, the ubiquity of pointer parameters yet lack of syntax to show data flow direction, the inability to specify the width of an enum value…

Despite everything, I do like C, especially compared to C++, but there's so many little things that could be improved and yet have been stagnant for decades. And that's without taking about the massive safety issues.

To play devil's advocate: it's because one size does not fit all. C gives you the flexibility to tailor your implementation for your specific needs. Whereas in a higher level language, you'd have to fight the language / standard library if your requirements don't match the "few" true ways to do things.

That said, too many projects believe they have special needs, when they're better served just using e.g. apr in the first place.

This argument does not make sense to me at all. C has a standard library, so why can't it be a good one? There's also many things about the language that could be improved without sacrificing any of its low-level qualities.

There are many reasons IMHO:

- C is designed by committee, so proposals to expand the standard library move slowly.

- Specifications suitable for general computing may not be so for embedded micro-controllers. TBF this is slowly changing as well, given that a ARM CortexM can have double-digit kilobytes of memory now, and is almost as fast as a PII.

- Philosophical: some C users maintain that C's supposed to be a "portable assembler" and higher level abstractions are beyond the scope[0].

This may sound tongue-in-cheek but: you should use C++ instead. Yes it has a lot of flaws of its own, but IMHO it really lives up to the spirit of being a "better C". It has (almost?) everything you said wanted in it standard library. And just because you're using C++ doesn't mean you have to go all-in with template meta-programming, objects, etc. I've written very C-ish code in C++, and only used parts of the C++ standard library I absolutely needed. Last time I did that I was able to "un-C++" my code later to satisfy upstream requirement (no capes!^W C++) relatively easily, after iterating with C++ first.

[0] I know there are counterarguments that C's never been that and it's more a "convenient lie." Nonetheless the that's the spirit of the argument.

C++ lacks some of the good things added to C after C89, unfortunately.

Other than restrict, with dubious usage validation, I fail to see what.

Finally, lack of vendor motivation.

Nobody's making big money on C compilers, no huge company with deep pockets feels they would benefit significantly from a "stronger" C.

Reply on news.ycombinator.com