
C Finally Gets A New Standard - Tatyanazaxarova
http://drdobbs.com/cpp/232800444
======
beza1e1
Usually 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>

------
exDM69
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?

~~~
octopus
If you don't like it use a typedef to make your code more "readable". Or a
macro that will replace every occurrence of mutex in your code with mtx.

However if you want to share your code with other people, I would go with the
standard names.

~~~
ArtB
Shouldn't the standard be as readable as possible and then use a typedef if u
r 2 lazy 2 type 2 mo lettrs?

~~~
tjoff
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.

~~~
ArtB
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"

~~~
tjoff
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_ ).

~~~
ArtB
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?

------
pkmays
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.

~~~
exDM69
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.

~~~
yxhuvud
On a similar note, what is up with thrd_timedout, thrd_success, thrd_busy,
thrd_error, thrd_nomem?

Why no ea's?

~~~
adestefan
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.

~~~
cpeterso
If the C committees want to avoid namespace collisions, why not use _Keyword
style names like _Mutex_init and _Mutex_destroy?

------
KaeseEs
I see they made the same mistake as POSIX threads in implementing recursive
mutexes. Disheartening.

~~~
sparky
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.

~~~
barrkel
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.

------
angersock
Would 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
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.

~~~
angersock
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.

~~~
lsiebert
Good documentation? I'm interested.

~~~
angersock
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.

------
fmstephe
Anyone have visibility on what the support for this looks like?

~~~
octopus
I would expect some support from gcc and clang.

~~~
garenp
Yup:

<http://gcc.gnu.org/projects/cxx0x.html>

<http://clang.llvm.org/cxx_status.html>

~~~
densh
I haven't seen anything about C11 there, only C++11.

------
program
1990 C90

2000 C99

2011 C11

so, if this is the trend expect a new C standard in 2022.

~~~
pjmlp
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.

~~~
ExpiredLink
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.

~~~
pjmlp
True.

Do you know if SQL 92 is finally fully supported across DB servers?

This was a nightmare back in the early 90's.

~~~
ExpiredLink
At least SQL 92 is the 'common denominator' among current relevant RDBMS.

------
cpeterso
/me looks at watch

Why did they name this standard C11 and not C12? To preserve name parity with
C++11?

~~~
garenp
It was standardized in late 2011. DrDobbs just takes it's DrTime to get out
those DrArticles. :)

------
eduadecastro
C++'s const correctness rules?

~~~
kzrdude
I don't know what exactly you are asking, but no, C11 doesn't have that.

