[boost] Re: integral_c on g++2.95.3

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
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?