On 11/06/2011 10:40 AM, Jonathan Wakely wrote:
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?
I think it would be very possible to have a general template library for
C++ that would handle a range of sizes and granularities. There would
be a few combinations that would correspond to the C types. These would
use the hardware implementation by template specialization.
I think the deeper issue is that there are two communities who are
interested in fixed-point math. 1. Embedded system folks who need an
efficient replacement for floating point that matches their hardware.
2. Systems programmers and financial types who want fixed-point like in
COBOL and Ada where you specify granularity and number of digits. I'm
saying both groups can be accommodated with care. I think even source
compatibility could be achieved with home headers.
