11–20 of 73 posts
1990 C90 2000 C99 2011 C11 so, if this is the trend expect a new C standard in 2022.
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.
This is specifically about the C programming language. Can we not conflate it with a different language entirely, at least in this comment thread?
1990 C90 2000 C99 2011 C11 so, if this is the trend expect a new C standard in 2022.
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.
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).
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.
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.
Why no ea's?
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?
I see they made the same mistake as POSIX threads in implementing recursive mutexes. Disheartening.
Recursive mutexes are useful when you need to implement multithreading a posteriori and cannot evaluate all the locking paths.
Earlier quoted context omitted.
Recursive mutexes are useful when you need to implement multithreading a posteriori and cannot evaluate all the locking paths.
When adding locking without evaluating all locking paths, how can you be sure none of those paths cause a deadlock ?
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?