Boost logo

Boost :

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2003-02-05 13:53:52

Gennaro Prota wrote:
> On Wed, 5 Feb 2003 10:30:01 -0300, "Fernando Cacciola"
> <fernando_cacciola_at_[hidden]> wrote:
>> "Gennaro Prota" <gennaro_prota_at_[hidden]> wrote in message
>>> Enumerations are not integral types. Also, the presence of next and
>>> prior exposes the use with enumerators to undefined behavior. Do we
>>> really want that?
>> Good point, however, I think that the *intent* of 'integral_c' is to
>> represent values that are 'integral constant expressions', which
>> includes enumerations besides ordinary integral type values.
> Yes, that was likely the intent. Actually I was imprecise when talking
> about undefined behavior; in general for constant expressions you have
> ill-formedness, not UB (at least when the constant expressions shall
> be evaluated during translation, as it is the case for N+1 and N-1 in
> integral_c). The relevant section of the standard is
> 5/5: If during the evaluation of an expression, the result is
> not mathematically defined or not in the range of
> representable values for its type, the behavior is undefined,
> unless such an expression is a constant expression (5.19), in
> which case the program is ill-formed.
> [incidentally I recently asked a clarification about it on
> comp.std.c++:
> ]
OK, I've read the thread and I agree with your interpretation and rewording.

> Now, it's not clear to me what happens in the following cases, where
> an explicit type conversion to enum appears:
> 1. #include <climits>
> enum e { e1 = 1 };
> int main() {
> char c [e( e1 +1 )];
> }
> The sub-expression e1 + 1 is ok and has type int

> , but what about e( e1 +1 )? Is the result of e1 + 1 in the range of
'representable values'
> for the enumeration?
If my readings of the std are correct:

[1] (e1+1) is an "arithmetic constant expression" since
    'e1' is an enumerator and '1' is a literal (5.3)

[2] e(e1+1) is, IMO, still a constant expression since it is a
    (function-style) cast to an enumeration type from a
    constant expression (5.1)

So, whether the expression is representable as 'e' is clearly
but (5.5) implies that since it is a constant expression, the implementation
is required to diagnose it if it turns out to be out of range for the

A similar argument holds for your second example.


I was suspicious of next/prior in integral_c<> from the beggining...
That's why I asked what was the intended role of integral_c<>,
and why does it feature next/prior.
If our interpretation is correct, next/prior would render the program
ill-formed in some usages of integral_c<> with enums, so, if it is
intended to represent 'integral constant expressions' and not just
'integral values' I think it should have next/prior removed.
Else, if it is intended to represent integral values, then we might
need a separate enum_c<>, or perhaps, "integral_const_expr<>".


Boost list run by bdawes at, gregod at, cpdaniel at, john at