21–30 of 73 posts
Earlier 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.
> 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?
Earlier 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.
Earlier 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?
Can anyone defend this?
Earlier quoted context omitted.
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.
I believe that has not been true for a long time, at the very least because some things are keywords in C++ that would be valid identifiers in C.
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.
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?
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?
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.
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 wonder what the ramifications would be if someone went through and properly named the functions.
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?
However if you want to share your code with other people, I would go with the standard names.