Re: What's wrong with C++?

[Ludovic Brenta <ludovic@ludovic-brenta.org>]

Hyman Rosen <hyrosen@mail.com> writes:
> On 2/17/2011 2:55 PM, Ludovic Brenta wrote:
>> Hyman Rosen<hyrosen@mail.com>  writes:
>>> And what does it mean for something to be
>>> "really an integer"?
>>
>> Simple: integers have arithmetic, enumeration values don't.
>
> C and C++ enumerations don't have arithmetic.
> They do convert automatically to integers, but
> they don't automatically convert back.

Actually they do in the example you provided:

    struct DamageType {
        enum E { Fire = 1, Acid = 2, Lightning = 4, Poison = 8 };
    };

    DamageType::E what_my_dragon_can_do =
        DamageType::E( DamageType::Acid | DamageType::Poison );

In this example, the two enumeration values are automatically promoted
to integer (which has arithmetic) ORed, then the result is automatically
converted back to the type DamageType::E.  Except that the value of
what_my_dragon_can_do is not one of the values defined in the type.

>>> Ada 'Pos and 'Val attributes certainly give the illusion that Ada
>>> enumerators are integers too!
>>
>> If you mean to say that Ada provides features for unsafe programming,
>
> Not at all, merely that it's easy within the language to convert back
> and forth between enumerations and integers.  Nothing unsafe about it.

Actually, there is something unsafe about it.  Ada programmers have both
integers and enumerations; they choose enumerations when arithmetic does
not make sense.  Converting enumerations to integers provides
arithmetic, which is unsafe for these types.  Actually, the only really
dangerous part is converting back to the enumeration type using 'Val.

>> Now try this and see your "illusion" shattered by reality:
>> type E is (A, B, C);
>> B : E := E'Val (E'Pos (A) + E'Pos (C)); -- Constraint_Error
>
> What illusion? I certainly know that Ada checks and C doesn't!

I meant the intentional illusion that you can treat enumerated values
like integers; you can't.

> Oh, and don't Ada implementers go insane because enumerations are
> supposed to provide the illusion of being consecutive even in the face
> of representation clauses which give them arbitrary underlying values?

The consecutiveness is embedded in the operations 'Pred and 'Succ, not
by 'Pos and 'Val.  It is true that validity checking is much more
difficult when the set of valid values is disjoint.  But it is a good
thing that compilers provide this functionality, instead of programmers
having to re-implement it each time.

> Also, I don't know if you did this intentionally or not, but you
> redefine the name B as a variable when it is already an enumeration
> literal. Do I recall correctly that this works because enumeration
> literals are "really" functions returning their value, and functions
> can be overloaded?

That was not intentional; my code doesn't compile.  Thanks for pointing
that out.

-- 
Ludovic Brenta.