On Sun, 18 Feb 2007 12:44:50 CST, Daniel Kr=FCgler wrote:

>On 18 Feb., 16:59, 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.

Yes, makes sense.

>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."

Ah, thanks :-) I didn't notice that.

>"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.

Yep. Off-hand the new section about conversion ranks looked simply
copied from C99 (except that the C++ draft doesn't use the concepts of
"width" and "precision": so it seems very intentional that C++ is
ruling out padding bits in integer types, whereas C99 allows them...
another sibling-rivals incompatibility) and I didn't pay attention to
it.

>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?

Oh, it was just for documenting one of my library facilities (I didn't
want to guarantee by contract that it would work with extended
types... the library is meant to work with any standard implementation
and supporting implementation-defined features isn't really worth the
bother)

>> (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 in the terminological sense: the words are IMHO too similar not
to cause confusion or oversights (in common parlance and in the
standard).

>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).

Yeah, that's another good point. And then, as noted in
Vandevoorde/Josuttis there could be support for floating-point
non-type template parameters in future versions of the language; so,
for instance, std::integral_constant should actually be called just
std::constant, as I did with my version:


<http://breeze.svn.sourceforge.net/viewvc/breeze/trunk/breeze/meta/consta=
nt.hpp>

>An interesting option would be to separate the meaning of integral
>and integer, thereby equating
>
>{integral types} =3D {integer types} U {enumeration types}

Yes, not sure how strongly-typed enums would fit in the scheme though.

Genny.

---
[ 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                      ]

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?

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.

(Incidentally, it would have been nice to solve once for all the
error-prone distinction "integer" vs. "integral")

Genny.

---
[ 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                      ]

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                      ]