C Finally Gets A New Standard
drdobbs.com
drdobbs.com
However if you want to share your code with other people, I would go with the standard names.
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.
Also, "mtx" could just as well be "matrix" as another posted mentioned they had used in their code. "mutex" can never be "matrix"
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).
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?
Not everybody will recognize mtx as mutex while reading code, and lots of people learn code by reading it, rather then from standards.
To have a distinction between mutex and "mtx c" on google will probably be of value as well.
mtx: maybe mutex? maybe multi-transaction? maybe library prefix? vendor prefix? maybe, maybe...
2 characters
I wonder what the ramifications would be if someone went through and properly named the functions.
(Keep in mind: identifiers ending in _t are reserved by POSIX. http://pubs.opengroup.org/onlinepubs/009695399/functions/xsh...)
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.
Why no ea's?
Can anyone defend this?
X -> B
B -> C
C -> B
Y -> 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.
We've got a library that mirrors a lot of this functionality really closely already.
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.
But yes, I do agree with your first paragrpah. And we're always open to friendly emails--see profile for contact info.
Really wish there was something like rdoc for C code--and no, Doxygen is fugly and fail.
2000 C99
2011 C11
so, if this is the trend expect a new C standard in 2022.
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.
Do you know if SQL 92 is finally fully supported across DB servers?
This was a nightmare back in the early 90's.
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).
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.
This is specifically about the C programming language. Can we not conflate it with a different language entirely, at least in this comment thread?
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.
Many C++ compilers actually are C/C++ compilers that decide what language to compile depending on command line flags and/or file name extension.
int* foo = malloc(sizeof(int));
int* foo = (int*)malloc(sizeof(int));
Why did they name this standard C11 and not C12? To preserve name parity with C++11?