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.
