Re: About "integral types"
On 18 Feb., 16:59, gennaro.pr...@yahoo.com (Gennaro Prota) wrote:
In the current working draft (n2134), paragraph 3.9.1/7 states:
Types bool, char, wchar_t, and the signed and unsigned integer
types are collectively called integral types
This sentence looks unchanged compared to C++98, but it relies on
other sentences (defining "signed/unsigned integer type") which *did*
change. In particular, the meaning of "signed/unsigned integer type"
now includes implementation-defined extended types. So, is the
sentence quoted above meant to include those ones too? Or was it just
not synchronized with the changes made earlier in the same section?
Just my personal 2 Cent: The current meaning (i.e. merging extendend
and standard integer types into integer types) *seems* to be intended.
Otherwise the standard would need to explicitly speak out the rules
concerning valid radices, behavour of unsigned arithmetic (para 4),
the
three supported representation types (para 7), etc. for the extended
types
also. Consider also that the integral promotion rules (4.5) have been
generalized by delegation to the integer conversion rank (4.13), which
*explicitely* rules standard and extended integer types, e.g.
"The rank of any standard integer type shall be greater than the rank
of
any extended integer type with the same size."
"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."
which implies the wish for uniform handling. This combined handling
also leeds
to some problems (see some of my currently active postings concerning
"basic
integral types", the missing IO inclusion of the extended integer
types, or the
incomplete header synopsis for numeric_limits), most probably just due
to
oversights in the wording at those places.
One issue here is that we have no longer a standard nomenclature to
denote the set { bool, char, wchar_t } U StandardIntegerTypes, which
is what I was looking for.
Yes, this might be a current gap - also for the type traits. May I
ask,
in which use case you needed this distinction?
(Incidentally, it would have been nice to solve once for all the
error-prone distinction "integer" vs. "integral")
In which sense do you mean that? Just the fact of the double existence
of this identifiers or some orthographic reasoning?
On the other hand there exist the terms "integral constant expression"
or "integral promotions/conversions" which *include* enumeration
types
(although they are excluded from integer/integral types).
An interesting option would be to separate the meaning of integral and
integer, thereby equating
{integral types} = {integer types} U {enumeration 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 ]