Every time I write C code.
Every time I write C code.
I think container types and algorithms is a fair point, but if you program C more you should have a go-to library or your own implementation.
One problem is that most C compilers accept implicit conversion between unrelated pointer types by default. If you accidentally pass a `const T*` to a function that takes a `T*`, you only get a warning. In C++ this is always a compiler error.
Another thing that I find very annoying (that is more about `const` in general): in C you cannot use `const` variables as compile time constants, instead you always have to use the preprocessor.
> but if you program C more you should have a go-to library or your own implementation.
Sure, but I still don't like the fact I need to find a third-party library (or roll my own) for the most basic data structures. Also, it's not like generic containers can be trivially implemented in C. They require lots of preprocessor magic and the resulting API will always be much worse than any equivalent C++ implementation, in particular with non-trivial types.
As for compiler time constants, you certainly can use them for those, but the compiler will happily identify constants without the const keyword, whose true purpose is to cause a build time error if you try to modify it.
Regarding libraries, see my other reply:
https://news.ycombinator.com/item?id=42506570
Libuutil is a system library that is on any system that uses ZFS, although there are no known external consumers, so if you are interested in being the first, feel free to open bug reports with OpenZFS asking for removed functionality to be restored if you want any of it.
No, you can't. In C, `const` variables are not constant expressions. This means you can't use them in case labels or to define the size of an array.
> Regarding libraries, see my other reply:
I know that there are several container libraries for C. I was only complaining that there is no standardized solution for the most basic data structures.
I do not agree about the APIs being worse than C++.
I also find you have some experience, know how to build good abstractions and have a set of good data structures, there is no issue with address complex problems in C.
I still dont think any programming language today capture what we had in the late 80s and 90s. But may be that is just nostalgia.
enum { nb = 1024 };
struct { int k, v; } hash[nb];
// 0 is an invalid key
void incr(int k)
{
int i = k % nb, j = i;
do {
int k2 = hash[i].k;
if (k2 && k2 != k) {
i = (i+1) % nb;
continue;
}
hash[i].k = k;
hash[i].v++;
return;
} while (i != j);
abort();
}
Apologies for the telegraphic variable names and weird control flow. I wrote this on my cellphone. Lacking these 15 lines are what keep you from writing C?There's a nice tutorial on hash tables in K&R, and I can also recommend learning about Chris Wellons's "MSI" hash table design, described in C at https://nullprogram.com/blog/2022/08/08/. He shows a more full featured hash table in about 30 lines of code, depending on what functionality you need. It's eminently practical, and usually a lot faster than generic algorithms.
That's not an exceptionally simple hash table either. One night I hurriedly wrote a rather long-winded implementation also on my cellphone (strings, with separate chaining and a djb-style hash function) and it also came to about 30 lines of code: http://canonical.org/~kragen/sw/dev3/justhash.c