I don't know. I added the equivalent to _Static_assert() to an assembler to run tests during assembly, it shouldn't be that hard for a compiler to do so at compile time (except to make compile time take a bit longer).
I read that as ‘no separate build target’, “no separate binary’, ‘unit tests run at compile time’. So, static_assert and compile-time evaluate both facilitate unit tests in a straightforward and reasonable way, that both isn’t there today and requires a lot more work to build out and maintain. Seems like an easy win for the standard, and if dlang’s importc is any indication, a healthy addition to the language.
I assumed that they meant something like rust’s builtin test stuff (and didn’t understand why that would be necessary) it didn’t occur to me that they considered a static assert to be a compile time unit test. You could certainly do actual consteval unittests in C++, I wonder how many people in your team would scream at you if you did so :)
I just want them to add several functions to the standard library for hash tables and maybe resizable arrays. Not even proper language support, just plain functions in the libc. Such a small addition for such common functionality.
It'd have no effect on existing codebases. No problems with backwards compatibility whatsoever. The only argument against it is it it might add a few kilobytes to an embedded libc.
Hash tables and lists in C are so simple to roll yourself in most cases that it hardly seems like a benefit. Why commit such a small addition to the standard library when guaranteed 99% of users will complain about it and end up rolling their own or pulling in a dependency anyway?
Hash tables and lists in C are so simple to roll yourself in most cases that it hardly seems like a benefit. Why commit such a small addition to the standard library when guaranteed 99% of users will complain about it and end up rolling their own or pulling in a dependency anyway?
Here's an argument for adding them. Correct and reasonably efficient hash tables and some form of dynamic lists are not simple for beginners to roll themselves. If they were in the standard library, then C would become far, far more approachable for new (and relatively new) programmers.
Maybe new and relatively new programmers should not use C. I don't have strong feelings about that one way or the other. But as you and dmpk2k seem to agree, the additions wouldn't add significant size to the standard library, and experts can simply ignore them and continue to write their own or use a third-party version that they prefer.
To put this another way, people can complain all they like (though I doubt that 99% of C coders would care that much), but nobody is harmed by such a small addition and some people are definitely benefitted.
the 99% is pulled out of thin air, but I think a couple of the other comments in this thread support me. A simple addition such as we're talking about here won't satisfy everybody, that's a given, but I'd also argue that it won't satisfy many or even most people. So, with that in mind, I suspect that all you'd be doing is catering to beginners, and that seems unecessary. Let beginners cut their teeth on Rust, golang, or C++ for a friendlier more approachable experience in a system programming language.
While C is a simple language in terms of syntax and stdlib, I think you'd agree, that doesn't make it a simple language to use in practice. I don't believe that adding a simple, beginner friendly, beginner focused, hash table or dynamic array to stdlib addreses the actual difficulties one encounters once they're situated with the language. I think the best way to address the difficulty of C in practice is to remove some of the footguns that are there today instead of, arguably, adding more. Make the language safer, for some definition of "safer", without introducing added complexity, and I think you'll have a more beginner tolerant language.
I also disagree that "reasonably efficient" hashtables in particular are not simple for beginners to roll themselves. Obviously, "reasonably efficient" is open to interpretation, and the application is clearly a factor, but a simple chained hash table? If you're using C already, beginner or not, I don't think it's unreasonable to expect you to be able to bang that out without too much trouble. Anything beyond that is probably more specialized that anything you'll find in stdlib today, hence, probably doesn't need to be there.
I don't think the original article addresses footguns specifically, but at a glance the items mentioned absolutely scratch an itch that I've had with C. And I think Walter's made other observations that are very much inline with improvements that everybody can benefit from, including beginners.
Thank you for that. I'm sure that's very much what @dmpk2k is looking for. I've never worked with posix (directly), I've never heard of nor encountered those routines. My C/C++ life was exclusively Windows, and it's been a while. However, judging from @kryptiskt's and @quasi_qua_quasi's comments below, I suspect that my argument against adding similar routines to stdlib still stands.
If you need a hashtable in C today, you're probably better off rolling your own. If you need something more sophisticated or robust, then use a library. The efforts of a standards body are better spent improving the language and the tooling.
It's subtle, but no standard C function allocates memory (or mentions if a function must/must not allocate memory) except for malloc(), calloc() and realloc(). It's probably intentional by this point.
Having to add forward declarations and header files is maddening indeed. One of the reasons I gave up on writing C for my own projects was those two. Just foolish busywork.
Sure there can be cases where one may want to have a modified header file, but in my projects that really never was the case.
Of the four items mentioned, forward declarations is the one that annoys me the most. I wish C could handle that, but doing so means the compiler would have to go through the source twice, which may impact compile times (although everybody complains about compile times anyway so ... )
I started my career writing C, and then a bit of C++, but I haven’t touched either language in anger in at least 20 years.
The other day I was reorganising some code and I realised the main loop was in the wrong place - at the top. So I moved it to the bottom where it belonged.
And then I asked myself, why? Why does it feel wrong to have it at the top? Doesn’t it make more sense to read top down? I really couldn’t understand why it felt so wrong.
And today I read this article, and now I remember why. Ugh!
drobilla | 6 hours ago
_Static_assert plus compile-time function evaluation does not a unit test make
spc476 | 2 hours ago
I don't know. I added the equivalent to
_Static_assert()to an assembler to run tests during assembly, it shouldn't be that hard for a compiler to do so at compile time (except to make compile time take a bit longer).esak | 3 hours ago
I read that as ‘no separate build target’, “no separate binary’, ‘unit tests run at compile time’. So, static_assert and compile-time evaluate both facilitate unit tests in a straightforward and reasonable way, that both isn’t there today and requires a lot more work to build out and maintain. Seems like an easy win for the standard, and if dlang’s importc is any indication, a healthy addition to the language.
olliej | 3 hours ago
I assumed that they meant something like rust’s builtin test stuff (and didn’t understand why that would be necessary) it didn’t occur to me that they considered a static assert to be a compile time unit test. You could certainly do actual consteval unittests in C++, I wonder how many people in your team would scream at you if you did so :)
dmpk2k | 3 hours ago
I just want them to add several functions to the standard library for hash tables and maybe resizable arrays. Not even proper language support, just plain functions in the libc. Such a small addition for such common functionality.
It'd have no effect on existing codebases. No problems with backwards compatibility whatsoever. The only argument against it is it it might add a few kilobytes to an embedded libc.
And yet here we are in 2023...
esak | 3 hours ago
Hash tables and lists in C are so simple to roll yourself in most cases that it hardly seems like a benefit. Why commit such a small addition to the standard library when guaranteed 99% of users will complain about it and end up rolling their own or pulling in a dependency anyway?
telemachus | 3 hours ago
Here's an argument for adding them. Correct and reasonably efficient hash tables and some form of dynamic lists are not simple for beginners to roll themselves. If they were in the standard library, then C would become far, far more approachable for new (and relatively new) programmers.
Maybe new and relatively new programmers should not use C. I don't have strong feelings about that one way or the other. But as you and dmpk2k seem to agree, the additions wouldn't add significant size to the standard library, and experts can simply ignore them and continue to write their own or use a third-party version that they prefer.
To put this another way, people can complain all they like (though I doubt that 99% of C coders would care that much), but nobody is harmed by such a small addition and some people are definitely benefitted.
esak | 41 minutes ago
the 99% is pulled out of thin air, but I think a couple of the other comments in this thread support me. A simple addition such as we're talking about here won't satisfy everybody, that's a given, but I'd also argue that it won't satisfy many or even most people. So, with that in mind, I suspect that all you'd be doing is catering to beginners, and that seems unecessary. Let beginners cut their teeth on Rust, golang, or C++ for a friendlier more approachable experience in a system programming language.
While C is a simple language in terms of syntax and stdlib, I think you'd agree, that doesn't make it a simple language to use in practice. I don't believe that adding a simple, beginner friendly, beginner focused, hash table or dynamic array to stdlib addreses the actual difficulties one encounters once they're situated with the language. I think the best way to address the difficulty of C in practice is to remove some of the footguns that are there today instead of, arguably, adding more. Make the language safer, for some definition of "safer", without introducing added complexity, and I think you'll have a more beginner tolerant language.
I also disagree that "reasonably efficient" hashtables in particular are not simple for beginners to roll themselves. Obviously, "reasonably efficient" is open to interpretation, and the application is clearly a factor, but a simple chained hash table? If you're using C already, beginner or not, I don't think it's unreasonable to expect you to be able to bang that out without too much trouble. Anything beyond that is probably more specialized that anything you'll find in stdlib today, hence, probably doesn't need to be there.
I don't think the original article addresses footguns specifically, but at a glance the items mentioned absolutely scratch an itch that I've had with C. And I think Walter's made other observations that are very much inline with improvements that everybody can benefit from, including beginners.
spc476 | 2 hours ago
While it's not part of the Standard C Library,
hcreate(),hsearch()andhdestroy()are mandated by POSIX. So there you go.kryptiskt | 2 hours ago
Don't ever use those, it's a terrible API. Like, once you want a second hashtable in your program, you have to use something else.
quasi_qua_quasi | 2 hours ago
From the looks of it, this managed a single global hash table, which strikes me as a really unpleasant API for nontrivial programs.
esak | 23 minutes ago
Thank you for that. I'm sure that's very much what @dmpk2k is looking for. I've never worked with posix (directly), I've never heard of nor encountered those routines. My C/C++ life was exclusively Windows, and it's been a while. However, judging from @kryptiskt's and @quasi_qua_quasi's comments below, I suspect that my argument against adding similar routines to stdlib still stands.
If you need a hashtable in C today, you're probably better off rolling your own. If you need something more sophisticated or robust, then use a library. The efforts of a standards body are better spent improving the language and the tooling.
spc476 | 2 hours ago
It's subtle, but no standard C function allocates memory (or mentions if a function must/must not allocate memory) except for
malloc(),calloc()andrealloc(). It's probably intentional by this point.nortti | an hour ago
aligned_alloc(), cnd_init(), thrd_create() (C11), strdup(), strndup() (C23)
fanf | 23 minutes ago
setvbufis a classic counterexample. C2z is likely to getaprintf.Aks | 3 hours ago
Having to add forward declarations and header files is maddening indeed. One of the reasons I gave up on writing C for my own projects was those two. Just foolish busywork.
Sure there can be cases where one may want to have a modified header file, but in my projects that really never was the case.
spc476 | 2 hours ago
Of the four items mentioned, forward declarations is the one that annoys me the most. I wish C could handle that, but doing so means the compiler would have to go through the source twice, which may impact compile times (although everybody complains about compile times anyway so ... )
doctor_eval | an hour ago
I started my career writing C, and then a bit of C++, but I haven’t touched either language in anger in at least 20 years.
The other day I was reorganising some code and I realised the main loop was in the wrong place - at the top. So I moved it to the bottom where it belonged.
And then I asked myself, why? Why does it feel wrong to have it at the top? Doesn’t it make more sense to read top down? I really couldn’t understand why it felt so wrong.
And today I read this article, and now I remember why. Ugh!