On 30 Apr., 01:51, Mathias Gaunard <loufo...@gmail.com> wrote:
> On 29 avr, 00:45, "Johannes Schaub (litb)" <schaub-johan...@web.de>
> wrote:
>
> > At 7.2/6 in the C++0x FCD, it says:
>
> > "It is implementation-defined which integral type is used as the
> underlying
> > type except that the underlying type shall not be larger than int unles=
s
> the
> > value of an enumerator cannot fit in an int or unsigned int."
>
> > Does "larger" mean not "long" or "unsigned long" etc.. Or does it mean
not
> a
> > type where "sizeof" is > than sizeof(int) ?
>
> Isn't that the same thing?

It wouldn't, if both int and long have the same size.
In other words: I assume that Johannes is asking
whether a feasible implementation could assign for

enum E { e };

an underling type of long in this case. IMO this
is not intended by the wording, see my own reply
to Johannes, which I hope will become available
soon.

HTH & Greetings from Bremen,

Daniel Kr=FCgler


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Apr 28, 6:45 pm, "Johannes Schaub (litb)" <schaub-johan...@web.de>
wrote:
> At 7.2/6 in the C++0x FCD, it says:
>
> "It is implementation-defined which integral type is used as the underlying
> type 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."
>
> Does "larger" mean not "long" or "unsigned long" etc.. Or does it mean not a
> type where "sizeof" is > than sizeof(int) ? Any hints? Thanks!

When implementing this, I read that to mean
* do not consider long, unsigned long, long long, or unsigned long
long unless unless neither int nor unsigned int can represent all of
the values.  (Note that the following will require upgrade on
(noncompliant?) targets where INT_MAX<UINT_MAX:)

#include <limits.h>

enum test
{
 x = -1,
 y = UINT_MAX
}

* when INT_MAX==LONG_MAX and INT_MIN==LONG_MIN, upgrade to long is
disallowed, and so on.
* on targets where INTMAX_MAX<UINTMAX_MAX, the following is a compiler
error (no integer type exists that can represent all values):

#include <stdint.h>
enum test
{
 x = -1,
 y = UINTMAX_MAX
}


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

At 7.2/6 in the C++0x FCD, it says:

"It is implementation-defined which integral type is used as the underlying
type 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."

Does "larger" mean not "long" or "unsigned long" etc.. Or does it mean not a
type where "sizeof" is > than sizeof(int) ? Any hints? Thanks!

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 29 avr, 00:45, "Johannes Schaub (litb)" <schaub-johan...@web.de>
wrote:
> At 7.2/6 in the C++0x FCD, it says:
>
> "It is implementation-defined which integral type is used as the
underlying
> type 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."
>
> Does "larger" mean not "long" or "unsigned long" etc.. Or does it mean not
a
> type where "sizeof" is > than sizeof(int) ?

Isn't that the same thing?

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Apr 29, 1:45 am, "Johannes Schaub (litb)" <schaub-johan...@web.de>
wrote:
> At 7.2/6 in the C++0x FCD, it says:
>
> "It is implementation-defined which integral type is used as the
underlying
> type 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."
>
> Does "larger" mean not "long" or "unsigned long" etc.. Or does it mean no=
t
a
> type where "sizeof" is > than sizeof(int) ? Any hints? Thanks!

The wording you quote is rather old and was written, before the
definition of an "integer conversion rank" as of [conv.rank] was
introduced. Given the context of the related requirements,
mentioned in the same paragraph, especially

"For an enumeration whose underlying type is not fixed, the
underlying type is an integral type that can represent all the
enumerator values defined in the enumeration. If no integral type
can represent all the enumerator values, the enumeration is
ill-formed."

it is intended to say that the underlying integral type shall be int
or unsigned int (depending on the remaining constraints) or an
integer of smaller type (measured in sizeof), if this type can
represent all enumerator values, otherwise it may select
any integral type that satisfies the representation-related
constraints.

With a re-use of the conversion rank definition this could be
described in a more specific/precise way. Effectively the current
wording would indeed allow for an implementation to use type
long instead of type int, if long and int would have the same
size and value ranges. I think, this was not intended by the
wording, but I also assume, it won't be fixed, unless someone
points to an implementation that does exactly so.

HTH & Greetings from Bremen,

Daniel Kr=FCgler


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]