On 6 November 2011 15:03, David Brown wrote: > Obviously C++ is going to get features that C does not - that's fair > enough. But it is seldom that there is a good reason for C++ not supporting > the additions to C standards. > > Some of the differences are just mind-boggling - C1x has got a > "_Static_assert" addition, while C++11 has "static_assert". They do the > same thing, but have a different keyword. Don't these people /talk/ to each > other? Do they make differences like this deliberately to annoy people - > both users and toolwriters?
What usually happens is that if C has claimed a new keyword already C++ will reuse it. When C++ has added a new keyword such as static_assert the C committee has preferred to add keywords in the reserved namespace. That's an engineering decision, based on the risk of breaking user code and weighed up against the reward of having more convenient names. The C++ committee are generally less fond of macros, so less willing to solve the problem via e.g. #define static_assert _Static_assert > gcc has always countered that to some extend, by allowing additional C > features to be used in C++. But even there there are limitations - there > are plenty of gcc extensions to C that are very useful, and for some reason > only work in C and not C++. I don't know how you're using "plenty" but I don't think there are that many, and the reason is obvious: the C and C++ front ends are not the same code. If a useful extension is missing from G++ you can create an enhancement request in bugzilla. > As a programmer, when I write portable code in C I want it to be valid C++ > as well. This gives the most flexibility, and the most efficient use of my > code. I don't want to have to re-write code to do the same thing in each > language, or to re-learn the differences. > > So to make "_Fract" and "_Accum" really useful, I need to be able to use it > in C and C++ code, and know that the types are compatible across the two > languages, and that the generated code will be equally efficient. Frankly, > as a user I don't really care whether it is implemented by a C++ library, a > gcc extension, mind-numbing macros, or whatever. It is absolutely fine if > the details are hidden within a "stdfix.h" header file. But what I /don't/ > want to end up with is a type called "signed short _Fract" in C and > "_fract<8>" in C++, or being unable to pass data between the languages, or > having to have C++ call external C functions just to get efficient > implementations. I think a better example is atomics support in C++11 and C11, where std::atomic<int> aka std::atomic_int can be exactly the same representation as _Atomic int and are compatible, but the C++ library solution also allows std::atomic<FooBar> which C doesn't. A *lot* of work went into ensuring the C++ atomics support included a subset that would be implementable in C. Why couldn't the same be done for _Fract?
