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

[David Brown]

On 05/11/11 18:29, Ed Smith-Rowland wrote:
> On 11/05/2011 08:36 AM, David Brown wrote:
>> On 04/11/11 20:35, 3dw4rd@verizon.net wrote:
>>> Greetings,
>>>
>>> Now that C++11 user-defined literals are in trunk I was thinking
>>> about reclaiming some of the numeric suffixes that are currently
>>> recognized by gcc in the preprocessor. The C++11 spec stipulates
>>> that any suffix that is recognized by the implementation is not
>>> allowable as a user-defined literal suffix in c++. This prevents C++
>>> from hijacking 123LL, 1.234L, etc. On the other hand, there are
>>> several numeric literal suffixes that are recognized and used as gnu
>>> extensions.
>>>
>>> One class of suffixes stands out in this connection: fixed-point
>>> literals. These end in 'k' or 'r' and can optionally be unsigned by
>>> starting with 'u' and optionally have a size 'h', 'l', 'll'. The
>>> difference for these suffixes is that fixed-point literals are
>>> explicitly rejected by the c++ front end. Attempts to use such
>>> literals: int i= 1.23k; results in 'error: fixed-point types not
>>> supported in C++'.
>>>
>>> So I ask the question: Should I make a simple change to libcpp to
>>> allow fixed-point literal suffixes to pass to the user-defined
>>> literal code in c++11 mode?
>>>
>>> Thanks,
>>>
>>> Ed Smith-Rowland
>>>
>>> P.S. There are other suffixes that might be reclaimed as well such as
>>> 'i', 'I', 'j', 'J' for complex integral or floating point imaginary
>>> numbers and others. These might be more difficult or impossible to
>>> reclaim for C++11 because these might be allowed and used in gnu-C++
>>> and it might break existing code.
>>>
>>
>> gcc has a tradition of allowing C-compatible features from C++ to be
>> supported in C, and useful features from C to be supported in C++.
>> Typically these being life as gcc extensions, but they sometimes move
>> into the standards (an easy example being gcc's support for C++
>> comments in C from long before C99 came out). An example is gcc's
>> support for C99-style "_Complex" floating point types in C++.
>>
>> Is there a good reason why the fixed point types (and decimal types,
>> and extended float types) are not supported in C++ as a gcc extension?
>> It strikes me that from the users' viewpoint it would be best for
>> these features to be available in C++ as well. If the actual
>> implementation of this would be difficult (I have no idea of the
>> effort involved here), then the next best thing is to reserve the
>> suffixes to avoid breaking things in the future, and to avoid user
>> confusion.
>>
>>
>>
> I think that fixed-point numbers would be an excellent addition to C++.
> The question is how to do it and what the semantics are.
>
> On one hand we could probably let the C fixed-point types and keywords
> and literals work in C++. IIRC C fixed-point extensions are rather
> limited in terms of what sizes and precisions are allowed.
>
> On the other hand, if we let C++ user-defined literals handle the
> literals then this opens the door to a pure library solution that would
> allow arbitrary size and precision and base for example. I tend to think
> the C++ committee would be more in favor of this because they tend to
> push library changes over language enhancements for flexibility. This
> would likely be a template library of some kind.
>
> Maybe there's a way to support both. IIRC the template specializations
> for complex use the corresponding _Complex types under the hood.
>

You are right that the standard C fixed-point types are limited, whereas 
a good C++ template based solution would be more flexible.  But the aim 
of the C types is that - where possible - they should be implemented 
using hardware processor support.  Many embedded processors, especially 
ones geared towards DSP, have direct support for scaled integer 
arithmetic.  The aim of N1169 is to provide standard C types that match 
the commonly used formats, to make fixed point code easier to write and 
more portable.

A C++ template class for "_Fract" support would be straightforward to 
write, and could easily support the formats in N1169.  But it would be 
very hard to do so in a way that generates small and fast code without 
resorting to inline assembly for targets that have hardware support for 
such features.

As you say, it is possible that both could be supported - using a 
template class to provide a generic solution, and using the C "_Fract" 
types for specialized classes.  The first step to that, however, is to 
allow the standard C "_Fract" types to work in C++ as a gcc extension.

The same principle applies to the decimal types and extended float types 
supported by C.