On 06/11/11 16:40, Jonathan Wakely wrote:
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
Yes, I can understand that there /are/ good reasons behind these
decisions - but it can be quite frustrating for the humble user who
merely sees inconsistencies.
And I do appreciate that many of these inconsistencies are hidden by
using header files (as mentioned by Joseph Myers in his reply), making
the differences mostly irrelevant to users.
Perhaps I have been getting too worked up about small things here, and
missing out on the major points, such as the efforts made to keep things
consistent through the use of header files. I still find it odd that
features are added in different ways in each language, then headers are
used to nullify the differences - but I thank you for your explanation
of /why/ there are these differences.
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.
I make the assumption that if a feature is in the C front end and not
the C++ front end, then there is a reason for that - though the reason
may be as simple as "no one has asked for this feature, so no one has
made it".
I suppose my desire to see a consistent _Fract implementation between C
and C++ is such an enhancement request, though it is made in this list
rather than 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?
If it can, then that would be marvellous, giving C++ users the choice of
the same efficient _Fract's as C (on platforms that support efficient
implementations, of course) and greater flexibility. My original
concern in this thread was that if the "r" and "k" _Fract suffixes were
freed for general use in C++, it would be difficult to use them later.
Thanks,
David
