Gennaro Prota wrote: > On Wed, 5 Feb 2003 10:30:01 -0300, "Fernando Cacciola" > <[EMAIL PROTECTED]> wrote: > >> >> "Gennaro Prota" <[EMAIL PROTECTED]> 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 paricularly >> 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++: > > http://google.com/groups?threadm=3p511v8da4difcutopta64vceusd9vd7r7%404ax.co m > ] > 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 OK > , 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 implementation-defined, 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 enumeration. A similar argument holds for your second example. Therefore... 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<>". Comments? _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost