Topic: Integer conversion rank implementation-defined?
Author: =?iso-8859-1?q?Daniel_Kr=FCgler?= <daniel.kruegler@googlemail.com>
Date: Sat, 21 Jul 2007 04:52:57 CST Raw View
The most recent draft N2315 says in [conv.rank]/p.1:
"The rank of any extended signed integer type relative to another
extended signed integer type with the same size is
implementation-defined, but still subject to the other rules for
determining the integer conversion rank."
Does that mean that an implementation is required to document
the rank values of extended integer types? Or is this an oversight
and should the word "implementation-defined" in this sentence be
changed to "unspecified"?
Assuming, it really should mean "implementation-defined", I
propose to follow the way, Fortran 90 does it with its "Kind"
values and to make them available for programmers, e.g. via
a new type trait. What about
template <class T> struct integer_rank;
?
Such a trait class would also allow programmers to write code
that deduces the real underlying type of an enumeration (which
is not unambigiously possible with a chain of sizeof tests).
N.B: From Sunday on I'm on vacations - Please don't wonder if
my answer follows later!
Greetings from Bremen,
Daniel Kr gler
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: =?iso-8859-1?q?Daniel_Kr=FCgler?= <daniel.kruegler@googlemail.com>
Date: Sat, 21 Jul 2007 10:15:54 CST Raw View
On 21 Jul., 12:52, Daniel Kr gler <daniel.krueg...@googlemail.com>
wrote:
> Does that mean that an implementation is required to document
> the rank values of extended integer types? Or is this an oversight
> and should the word "implementation-defined" in this sentence be
> changed to "unspecified"?
I should probably not write a posting too late in the night ;-)
After rereading the paragraph it seems clear that the intent seems to
be that implementors shall indeed publish the *relative* ranks of
extended types, e.g.
rank(short) < rank(some_ext_type) < rank(int)
On the other hand this awareness does not really invalidate the
question of my OP, whether a new type trait like integer_rank
should be provided. It's already clear that there exists a well-
defined
ordering of the ranks among the integer types, that bool has the
lowest value, etc. This trait would also provide a self-documentation
of the required relative ordering for extended integer types.
Greetings from Bremen,
Daniel Kr gler
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]