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.
Is mutex more readable than mtx? Readability only matters for the programmer that is supposed to know what mtx/mutex is (regardless of the name) and the name itself of course, naming it mtx rather than mutex incurs no extra overhead to learn or understand. If anything the code is less cluttered and more to the point (without sacrificing anything (IMO)), but I don't see why I'd care.
Designing for people that don't know anything about what they do isn't a goal worth pursuing, the only thing you might succeed with is tricking someone into thinking they know something - in which case you've just made it worse.
Yes, it definitely matters I think. It's just an extra little bit of work to understand, which when you are debugging you needs as little mental clutter as possible. Why make something more work than it needs to be? Code is read more often then it is written therefore one ought to optimise for reading.
Also, "mtx" could just as well be "matrix" as another posted mentioned they had used in their code. "mutex" can never be "matrix"
Of course readability matters. But you must know language constructs anyway, no need for them to be overly explicit and be in the way of your code - therefor it could easily be argued that "mtx" is easier and more optimized for reading than "mutex".
The only reason an "if" or "while" statement makes sense to every programmer isn't because it is readable but because you must know the syntax and semantics of the language you program. And having a good shorthand is faster to read and since mtx isn't a word it isn't associated as anything that could be a word but you instantly see it as a language construct (kind of like syntax highlighting) and thus reduces the work of mentally parsing the code (one advantage of not writing your code in English is that you subconsciously see the language constructs differently than any of the code that you wrote yourself, not saying that I prefer to do this or recommend it (on the contrary)).
Again, this example alone isn't one I'd really care about - just questioning that "mutex" would be more readable than "mtx" (as a language construct).
I think I'm going to flip this around and say can you argue for why the keyword shouldn't be to use the "default position" of using the real word when its only two characters more?
The flaw in your argument is that what's "readable" changes dramatically over time. Once a programmer has used it enough times, "mtx" will be every bit as readable as "mutex". The brain readily tokenizes what it's seen before. Thus the case for plain-English-readability in code is limited to programmers who are not yet familiar with a notation – not a strong general case. We ought to have learned this from COBOL and every other attempt to make programming languages be like natural language.
Code is read more often than it is written, therefore one ought to optimise for reading
But by the same logic, code is read more often by people who know the language and most often by people who have been working on the program for a while, so they are the ones we should optimize for. The readability test that matters for maintaining a complex system over time is hardly "can someone unfamiliar with both the language and the program dive in to any random function and make out what it's doing". So why is that the standard always held up in discussion?
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.
I recently found myself reading Mason & Dixon and trying to figure out what the rule is for those apostrophes. Pynchon wrote that book in a hybrid of 18th and 20th century English (which is brilliant and possibly also annoying) and boy does he apostrophize. At first it seemed like all the past forms were apostrophiz'd but then I noticed many of them were elongated after all. It appears that the rule is to spell out the "e" in "ed" when it's articulated and use an apostrophe when it's unpronounc'd. I suppose this ought to have been obvious from first principles but I only hit on it by painstaking induction :)
To be fair, it should be "created." I was making a joke based on the fact that the original function name to create a file in C was in fact called "creat". If I added the (pronounced) "e", then the joke would be lost!
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.
The 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.
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.
If 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.
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.
The 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.
Nobody is obliged to implement a new standard. C90 is a Standard, C99 is another one. 'Newer is better' is a fallacy. SQL 92 Intermediate Level e.g. is the most important SQL Standard.
A fast moving standard is not necessarily a bad thing, provided that changes don't break backwards compatibility.
In some ways, I'd like the C standard to move a bit faster, to keep up with things like multi-threading (although there's an argument to be had over whether that should be defined as part of the language or left to vendor-specific libraries).
> A fast moving standard is not necessarily a bad thing, provided that changes don't break backwards compatibility.
Another problem is that the standard becomes irrelevant. This is a concern for HTML5, because a 'rapidly evolving' standard means that things can be added prematurely - but once something is in the standard, it can't be removed (easily). At some point, you run the risk of having more companies go the Microsoft route and just abandon the standard altogether, and either stick with an older version, or just fork it into their own new language.
Aaaaand that's why they've added these ops. Note that it took a while (> decade) to really find out that these features were reasonable to assume support for. :)
Yea, 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.
I don't really know C++ as well as I know C - could you explain? I always thought that the only real reason C++ wasn't a superset is because of the additional keywords.
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf