My biggest problem with the new standard is the awkward naming of the threading functions. "mtx" over "mutex" saves a whole 2 bytes. Now what's up with that? Trying to avoid a namespace clash with some existing widely used library or something?
That's usually something that bothers me about C and it's libraries. I don't see the point in saving those bytes when we aren't really typing them anymore (because of modern text editors and IDEs.) Abbreviation makes the code look uglier and more cryptic, I know that appeals to some coders, but not me.
Back when C was first pioneer'd this was an issue. However this is the 21st century and yes we could have better full names but the standard from before is kept for consistency. I think deprecation and renaming of everything is out of the question at this point as companies and developers have invested considerable amounts of time in building applications using the good ole "fprintf" or "malloc".
I wonder what the ramifications would be if someone went through and properly named the functions.
Haven't read the document yet, so I don't know if there's a rationale for naming.
It might simply be racial memory, from the days of linkers with eight character symbols (and the initial underscore ate one of them). It's hard to believe we actually wrote software under those limitations.
The threads.h header comes directly from the Dinkumware Compleat C library. I would have preferred a stdthread.h with more pthread.h like struct/function naming.
It seems to me if ANY one group of people should be allowed to add new keywords to the user namespace, it should be the standard bearers. The whole _Keyword thing is something only a committee could love.
The whole _Keyword thing is to make it easier to port from older C standards to the new standard. It's not really supposed to be programmer-visible, only a workaround for compilers. There is an extensive explanation about the reasoning behind this solution in the spec. Read that and come back if you still have a problem with making forward-compatibility hacks.
Of all the ways to shoot yourself in the foot with C, recursive mutexes seem relatively benign. The implementation is a handful of lines of code, and they're not always a symptom of bad design, either; imagine needing to lock each node in a path through a (possibly cyclic) graph.
I would bet that most people who want to use it also have a similar library. For the thread stuff I just adhered to the pthread interface, and for atomic operations, I grabbed similar functions from the Linux kernel. (If you need code to do a low-level systems thing, chances are the Linux kernel needs it too. Fantastic resource.)
I see this as a standard that's less providing new things, but providing consistent names and interfaces to things many people already do. Personally, I had always seen Pthreads as the defacto thread, mutex and condition variable standard for C. But it makes sense to define one outside of Pthreads for non-POSIX platforms, particularly if you already need to add atomic and thread-local to the standard.
[+] [-] beza1e1|14 years ago|reply
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
[+] [-] exDM69|14 years ago|reply
[+] [-] krollew|14 years ago|reply
[+] [-] MarceloRamos|14 years ago|reply
[+] [-] octopus|14 years ago|reply
However if you want to share your code with other people, I would go with the standard names.
[+] [-] warmwaffles|14 years ago|reply
I wonder what the ramifications would be if someone went through and properly named the functions.
[+] [-] pagekalisedown|14 years ago|reply
[+] [-] kabdib|14 years ago|reply
It might simply be racial memory, from the days of linkers with eight character symbols (and the initial underscore ate one of them). It's hard to believe we actually wrote software under those limitations.
[+] [-] jongraehl|14 years ago|reply
[+] [-] pkmays|14 years ago|reply
[+] [-] pkmays|14 years ago|reply
[+] [-] exDM69|14 years ago|reply
[+] [-] KaeseEs|14 years ago|reply
[+] [-] sparky|14 years ago|reply
[+] [-] shin_lao|14 years ago|reply
[+] [-] angersock|14 years ago|reply
We've got a library that mirrors a lot of this functionality really closely already.
[+] [-] scott_s|14 years ago|reply
I see this as a standard that's less providing new things, but providing consistent names and interfaces to things many people already do. Personally, I had always seen Pthreads as the defacto thread, mutex and condition variable standard for C. But it makes sense to define one outside of Pthreads for non-POSIX platforms, particularly if you already need to add atomic and thread-local to the standard.
[+] [-] fmstephe|14 years ago|reply
[+] [-] maximilianburke|14 years ago|reply
[+] [-] octopus|14 years ago|reply
[+] [-] program|14 years ago|reply
2000 C99
2011 C11
so, if this is the trend expect a new C standard in 2022.
[+] [-] pjmlp|14 years ago|reply
http://en.wikipedia.org/wiki/C99 http://en.wikipedia.org/wiki/C11_%28C_standard_revision%29
Microsoft as typical bad boy attitude already said it only cares about C89, as everything else can be done with C++ anyway.
And as they don't care about portability this is unlikely to change, unless they are pressured to change like it happened with IE.
[+] [-] twsted|14 years ago|reply
[+] [-] shin_lao|14 years ago|reply
[+] [-] cpeterso|14 years ago|reply
Why did they name this standard C11 and not C12? To preserve name parity with C++11?
[+] [-] garenp|14 years ago|reply
[+] [-] eduadecastro|14 years ago|reply
[+] [-] kzrdude|14 years ago|reply