Re: [C++11] Reclaiming fixed-point suffixes for user-defined literals.

[David Brown <david dot brown at hesbynett dot no>]

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