[C++-sig] Re: Re: Re: Re: enum_ exporting implemented

Mike Rovner mike at bindkey.com
Sat Dec 14 03:18:36 CET 2002


"David Abrahams" <dave at boost-consulting.com> wrote in message
news:u3cp1l85h.fsf at boost-consulting.com...
> "Mike Rovner" <mike at bindkey.com> writes:
>
> > "David Abrahams" <dave at boost-consulting.com> wrote in message
> > news:u4r9hmozd.fsf at boost-consulting.com...
> >> "Mike Rovner" <mike at bindkey.com> writes:
> >>
> >> >> >>>> identity(color(3))
> >> >> > enums.color(3)
> >> >> >
> >> >> > a mistake? There is no 3 in example enum.
> >> >
> >> > I mean not how it is working, but how it shall work.
> >> > If it's a legitimate behavior, please, explain why.
> >>
> >> It mirrors the behavior of C++ enums.
> >
> > Shall we follow all bad design? ;)
>
> Yes <wink>.  Especially without any justification for calling it "bad"
>
> >> Why do you think it's illegitimate?
> >
> > Because there is no 3 in original enum.
> >
> >> What do you think enums.color.red + enums.color.green should do?
> >
> > Return integer 3.

Now color.red+color.blue doesn't return color(5) but simply 5.
It's not consistent with color(3) above. Unlike C++ Python doesn't have
compile-time constant
simplification (am I right?), so it's an expression.
imho propagation of enums to python shall be restricted only to explicitly
declared constants.

> > (Like in Python: False + True is just 1 and only for backward
compatibility
> > imho)
>
> In this case, enums are often used for flag values, and combinations
> of the flags are common.  It is a fact that all values with the same
> number of bits as the maximum value of the enum are legitimate values
> of the enum in C++, even if they're never named.  It simply wouldn't
> work right if values not explicitly exported were not allowed, and
> requiring the user to export all 2147483648 possible values of her
> enum is IMO impractical.

Sure, but the key difference in constant vs. expresiion.
Also we can do

enum { x=1, y, z };

Then y+z is 5 which is outside maximum bitrange of that enum and therefore
is not the same C++ type,
but still make sense for flags. So is shall be just integer from python
side.

> > All that is IMHO without pretending to know better.
>                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Yeah, right!

Can we still discuss it?

--------------------

Well may be I just dumb minded (today !? ;))
Can you kindly explain *Python* semantics of color(3) above.
It just make no sense for me, though I understand C/C++ heritage, etfc...
Thanks in advance.









More information about the Cplusplus-sig mailing list