51–60 of 73 posts
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?
Earlier quoted context omitted.
On a similar note, what is up with thrd_timedout, thrd_success, thrd_busy, thrd_error, thrd_nomem? Why no ea's?
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.
Why did they name this standard C11 and not C12? To preserve name parity with C++11?
Earlier quoted context omitted.
mtx_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... )
[deleted]
Earlier quoted context omitted.
True, but new standards don't mean that they get support in all compilers. 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…
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.
Do you know if SQL 92 is finally fully supported across DB servers?
This was a nightmare back in the early 90's.
Earlier quoted context omitted.
Shouldn't the standard be as readable as possible and then use a typedef if u r 2 lazy 2 type 2 mo lettrs?
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 kn…
Not everybody will recognize mtx as mutex while reading code, and lots of people learn code by reading it, rather then from standards.
Earlier quoted context omitted.
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 name…
Our 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.
Earlier quoted context omitted.
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 kn…
When I google search for just mtx, it's all car audio, whereas mutex gives a wikipedia result for mutual exclusion as the first link. 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.
Earlier quoted context omitted.
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 neve…
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 langua…
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?