Re: G++ enums 'underlying type'

[Paul Schlie <schlie at comcast dot net>]

> From: Gabriel Dos Reis <gdr@integrable-solutions.net>
> | Paul Schlie <schlie@comcast.net> writes:
> | > From: Paolo Carlini <pcarlini at suse dot de>
> | > assuming something specific about g++ 'underlying type' (7.2/5) will alow
> me
> | > to remarkably simplifiy the implementation of tr1/type_traits/is_enum: is
> it
> | > signed or not? Basing on some simple experiments on x86, seems always wide
> | > either like an int or a long: is this correct in general?
> | 
> | To my understanding, C enums need only be represented as the smallest rank
> | signed or unsigned integer type capable of representing it's value range
> | (although GCC tends to first unnecessarily promote enums to int, which I
> | believe is officially the largest enum equivalent type, and then back them
> | down opportunistically; keeping their converted form as small as possible is
> | significant to small machine targets, so they should not be unnecessarily
> | represented as being any larger than necessary, just as bool/char/short
> | types should not be needlessly promoted).
> 
> In C, enumerator are ints -- even though the associated enumeration
> type is considered a distinct types.  Only C++ allows for the smallest
> integer type as the underlying type; and C++ enumerators are not ints.

Converted to integer type of compatible rank, not "int"

 6.3  Conversions
 ...

 -- The rank of any enumerated type shall equal the rank of
            the compatible integer type.

 ...


(in general, bool, enum, and smaller than int rank types need not
 be promoted by GCC to "int" without need for the precision of a
 representation of greater rank, which is most often unnecessary;
 therefore typically misrepresenting of the minimal necessary
 rank representation of an arbitrary expression; in fact, many
 minimal rank representation may actually demote their arguments
 and maintain full compliance with C specified evaluation results.)