10 ms·
C Finally Gets A New Standard
- beza1e1 15y agoUsually the latest draft is available for free and has the same content as the standard. That should be the N1570 document. http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
- KaeseEs 15y agoI see they made the same mistake as POSIX threads in implementing recursive mutexes. Disheartening.
- sparky 15y agoOf 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.
- barrkel 15y agoIf two different threads were trying to lock different paths that entered the same cycle at different nodes, there can be a deadlock. X -> B B -> C C -> B Y -> C Thread 1 tries to lock X B C; thread 2 tries to lock Y C B; deadlock with 1 holding X and B, 2 holding Y and C. It's possible that your paths may be more restricted than this, but I reckon keeping the paths and cycles clean would be a bigger problem than recursive mutexes.
- shin_lao 15y agoRecursive mutexes are useful when you need to implement multithreading a posteriori and cannot evaluate all the locking paths.
- program 15y ago1990 C90 2000 C99 2011 C11 so, if this is the trend expect a new C standard in 2022.
- shin_lao 15y agoC/C++ is used to build the fundation of pretty much everything you use every day. I don't think a fast moving standard would be a good thing.
- derleth 15y ago> C/C++ This is specifically about the C programming language. Can we not conflate it with a different language entirely, at least in this comment thread?
- Retric 15y agoI was under the impression the C++ standard moves in lockstep with C so that all valid C programs should also be valid C++ programs.
- adrianN 15y agoI believe that has not been true for a long time, at the very least because some things are keywords in C++ that would be valid identifiers in C.
- Retric 15y agoYea, after looking into it they don't seem to be completely compatible anymore. I have known many people to use a C++ compiler when writing C code, but it looks like that restricts you to a subset of C. They do try and stay reasonably consistent so for example Long Long moved from C to C++. And C99 has reduced some other incompatibilities by incorporating C++ features such as // comments and mixed declarations and code. http://en.wikipedia.org/wiki/Compatibility_of_C_and_C%2B%2B http://en.wikipedia.org/wiki/Compatibility_of_C_and_C%2B%2B
- pkmays 15y agoIt 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.
- exDM69 15y agoThe 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.
- yxhuvud 15y agoOn a similar note, what is up with thrd_timedout, thrd_success, thrd_busy, thrd_error, thrd_nomem? Why no ea's?
- mattgreenrocks 15y agoThat's horrible. I read it the first time as "third success." At least "mtx" is a little easier to see (though still quite silly). Can anyone defend this?
- adestefan 15y agoThe Cxx committees try really had to make everything backwards compatible. This includes trying to not step on existing namespaces. These names, along with mtx, etc., are just going overboard though.
- cpeterso 15y agoIf the C committees want to avoid namespace collisions, why not use _Keyword style names like _Mutex_init and _Mutex_destroy?
- exDM69 15y agoMy 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?
- pagekalisedown 15y agoThis is annoying. This will conflict with the matrices in my code.
- rcfox 15y agomtx_init and mtx_destroy might. The rest of the mtx_* keywords don't seem like they'd be used for a matrix library. (Keep in mind: identifiers ending in _t are reserved by POSIX. http://pubs.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_02.html http://pubs.opengroup.org/onlinepubs/009695399/functions/xsh...)
- deleted 15y ago[deleted]
- deleted 15y ago[deleted]
- jongraehl 15y agohttp://bikeshed.com http://bikeshed.com
- krollew 15y agoI think because such naming is used in all standard C library.
- MarceloRamos 15y agoThat'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.
- fmstephe 15y agoAnyone have visibility on what the support for this looks like?
- octopus 15y agoI would expect some support from gcc and clang.
- maximilianburke 15y agoClang and GCC both have limited support for C11 currently, which can be enabled by compiling with -std=c11.
- eduadecastro 15y agoC++'s const correctness rules?
- kzrdude 15y agoI don't know what exactly you are asking, but no, C11 doesn't have that.
- angersock 15y agoWould anyone here be interested in a shim to play with this stuff before the compiler vendors add support? We've got a library that mirrors a lot of this functionality really closely already.
- scott_s 15y agoI 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.
- angersock 15y agoOur library is mainly focused on cross-platform (Windows, Linux, OSX, Solaris, etc.) and developer ergonomics (Good documentation, orthognal and clean features, descriptive names, etc.). But yes, I do agree with your first paragrpah. And we're always open to friendly emails--see profile for contact info.
- lsiebert 15y agoGood documentation? I'm interested.
- angersock 15y agoThe stuff on our site (see profile) is pretty well documented in the .h files... our next release (hopefully in a week or two) will offer something like MSDN-style overview pages along with detailed function docs. Really wish there was something like rdoc for C code--and no, Doxygen is fugly and fail.
- cpeterso 15y ago/me looks at watch Why did they name this standard C11 and not C12? To preserve name parity with C++11?
- garenp 15y agoIt was standardized in late 2011. DrDobbs just takes it's DrTime to get out those DrArticles. :)