
Boost : 
From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 20030205 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
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
> illformedness, not UB (at least when the constant expressions shall
> be evaluated during translation, as it is the case for N+1 and N1 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 illformed.
>
> [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 subexpression 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
(functionstyle) cast to an enumeration type from a
constant expression (5.1)
So, whether the expression is representable as 'e' is clearly
implementationdefined,
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
illformed 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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk