On 6 November 2011 15:03, David Brown wrote:
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
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?