Anyone have visibility on what the support for this looks like?
I would expect some support from gcc and clang.
C Finally Gets A New Standard
31–40 of 73 posts
Re: C Finally Gets A New Standard
#32My 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?
This is annoying. This will conflict with the matrices in my code.
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...)
Re: C Finally Gets A New Standard
#33Anyone have visibility on what the support for this looks like?
Clang and GCC both have limited support for C11 currently, which can be enabled by compiling with -std=c11.
Re: C Finally Gets A New Standard
#34Earlier quoted context omitted.
> 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?
I was under the impression the C++ standard moves in lockstep with C so that all valid C programs should also be valid C++ programs.
That's Objective-C.
int* foo = malloc(sizeof(int));
Re: C Finally Gets A New Standard
#35Earlier quoted context omitted.
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.
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.
Re: C Finally Gets A New Standard
#36My 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?
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.
Shouldn't the standard be as readable as possible and then use a typedef if u r 2 lazy 2 type 2 mo lettrs?
Re: C Finally Gets A New Standard
#37Earlier quoted context omitted.
C/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.
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).
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. :)
Re: C Finally Gets A New Standard
#38Would 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.
Re: C Finally Gets A New Standard
#391990 C90 2000 C99 2011 C11 so, if this is the trend expect a new C standard in 2022.
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.
Re: C Finally Gets A New Standard
#40Would 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.
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.