Kevin J. Hopps <khopps@Adobe.COM> writes:

> The C++ Public Review Document says
>
> 5 The  underlying  type  of  an enumeration is an integral type that can
>   represent all the enumerator values defined in the enumeration.  It is
>   implementation-defined  which  integral type is used as the underlying
>   type for an enumeration except that the underlying type shall  not  be
>   larger than int unless the value of an enumerator cannot fit in an int
>   or unsigned int...
>
> Consider
>  enum { a = -1, b = 0xffff };
>
> For a machine with 16 bit ints and 32 bit longs, the PRD seems to
> contradict itself.  The first sentence seems to say that the underlying
> type would have to be long, since neither an int nor an unsigned int can
> hold both -1 and 65535.  But the second sentence seems to say that the
> underlying type cannot be larger than an int, because all enumerators
> can fit in either an int (-1) or an unsigned int (65535).

I think that are correct, the quatifier is at the wrong position:

for each enumerator (fits in int or fits in unsigned int)

vs

for each enumerator (fits in int)
or for each enumerator (fits in unsigned int)

Added to my list of problems. I propose the following wording:

|>   The underlying type shall  not  be
|>   larger than int (unless logically necessary).

At least we are sure it doesn't lead to a contradiction !

The std doesn't say that the underlying type depends only on
the enumerators' values, not the name of the enumeration being
defined, or some other criteria. Which makes the statement
that [if there is no enumerator, a dummy enumerator with value 0
is added] a bit strange, because it doesn't imply anything.

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://pages.pratique.fr/~bonnardv/


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

The C++ Public Review Document says

5 The  underlying  type  of  an enumeration is an integral type that can
  represent all the enumerator values defined in the enumeration.  It is
  implementation-defined  which  integral type is used as the underlying
  type for an enumeration except that the underlying type shall  not  be
  larger than int unless the value of an enumerator cannot fit in an int
  or unsigned int...

Consider
 enum { a = -1, b = 0xffff };

For a machine with 16 bit ints and 32 bit longs, the PRD seems to
contradict itself.  The first sentence seems to say that the underlying
type would have to be long, since neither an int nor an unsigned int can
hold both -1 and 65535.  But the second sentence seems to say that the
underlying type cannot be larger than an int, because all enumerators
can fit in either an int (-1) or an unsigned int (65535).

Kevin Hopps, Adobe Systems Incorporated.


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article 100A@adobe.com, "Kevin J. Hopps" <khopps@Adobe.COM> writes:
>The C++ Public Review Document says
>
>5 The  underlying  type  of  an enumeration is an integral type that can
>  represent all the enumerator values defined in the enumeration.  It is
>  implementation-defined  which  integral type is used as the underlying
>  type for an enumeration except that the underlying type shall  not  be
>  larger than int unless the value of an enumerator cannot fit in an int
>  or unsigned int...
>
>Consider
> enum { a = -1, b = 0xffff };
>
>For a machine with 16 bit ints and 32 bit longs, the PRD seems to
>contradict itself.  The first sentence seems to say that the underlying
>type would have to be long, since neither an int nor an unsigned int can
>hold both -1 and 65535.  But the second sentence seems to say that the
>underlying type cannot be larger than an int, because all enumerators
>can fit in either an int (-1) or an unsigned int (65535).

A given enum can have only one underlying type.

If that type were int in your scenario, it could not represent
the value of b. If it were unsigned int, it could not represent
the value of a. Therefore the underlying type cannot be either of
those.

Possibly the wording could be improved, but I think the meaning is clear.

---
Steve Clamage, stephen.clamage@sun.com



[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Kevin J. Hopps wrote:
>
> The C++ Public Review Document says
>
> 5 The  underlying  type  of  an enumeration is an integral type that can
>   represent all the enumerator values defined in the enumeration.  It is
>   implementation-defined  which  integral type is used as the underlying
>   type for an enumeration except that the underlying type shall  not  be
>   larger than int unless the value of an enumerator cannot fit in an int
>   or unsigned int...

They obviously wanted to say s.th. like:
"... unless the values of all enumerators cannot fit in an int or
unsigned int at the same time."

>
> Consider
>         enum { a = -1, b = 0xffff };
>
> For a machine with 16 bit ints and 32 bit longs, the PRD seems to
> contradict itself.  The first sentence seems to say that the underlying
> type would have to be long, since neither an int nor an unsigned int can
> hold both -1 and 65535.  But the second sentence seems to say that the
> underlying type cannot be larger than an int, because all enumerators
> can fit in either an int (-1) or an unsigned int (65535).

Each enumerator fits into an int or unsigned int, but all enumerators
together don't fit into an int (because of 0xffff) or an unsigned int
(because of -1).
However the draft as written does make a statement about the single
enumerators. Maybe this was fixed for the standard (anyone having
the FDIS to check?)

BTW, does the standard tell how to handle the following case?

enum { a=-1, b=ULONG_MAX };

Since there's obviously no integral type which can hold all
values, should the compiler
- use signed long (therefore casting ULONG_MAX)?
- use unsigned long (therefore casting -1)?
- give an error message?


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]