[Pyrex] More on enums in 0.9.5.1a

[Lenard Lindstrom]

Greg Ewing wrote:
> Lenard Lindstrom wrote:
>
>   
>> That wouldn't be allowed because (e + 1) could be an invalid value for
>> the enum.
>>     
>
> Yes, I can see why, but it means that C++ enums
> don't have any straightforward equivalent of Pascal's
> pred() and succ() operations -- which is probably what
> you're trying to do if you write e = e + 1.
>
> This is an analogous issue to bounds checking of
> array indices and pointer arithmetic, which C and
> C++ are normally quite happy to not bother doing.
> To suddenly get all paranoid when it comes to
> enum ranges seems a bit inconsistent.
>
>   

Yes it does appear odd. I can only suggest the following. A pointer
represents an open range of values limited only by the hardware. It has 
well defined arithmetic. That a pointer can have an invalid memory 
address is not only understood but is also put to use. The index 
operation on a C array is syntactic sugar. An enumeration represents a 
limited set of discrete, not necessarily contiguous, values. Assigning a 
calculated value to one is a possible coding error. It's safer to 
require an explicit cast in this case.

Of course C++ is too low level a language to support succ() and prec() 
operations directly. It might have to generate an entire switch 
statement implicitly! So adding that kind of functionality is left as an 
exercise for the programmer. One has to justify templates and classes 
somehow.


-- 
Lenard Lindstrom
<len-l at telus.net>