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, 3dw...@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.
