Re: [boost] BOOST_ENUM proposal

From: Frank Laub (frank.laub_at_[hidden])
Date: 2005-12-07 17:19:34

Also: does your implementation cope with defining an enum inside a class?
> (I could live with an answer of "No" - I would just have to put the enum
> outside the class.)

Nope, currently this doesn't work. Maybe there's some trick to perform here?

Is your implementation limited to 255 elements (normal boost preprocessor
> limit)?

Yes, its actually limited the max number of elements in a sequence, divided
by 2.

Can I specify enum values (ie Abort=0, Info=16)?

I was just experimenting with that, and while the compiler does not complain
if you do that, the parse() function simply doesn't work. I'd need a
separate data element to describe the value portion, and then I'd have to
throw that into a map so that parse can look it up by that value.
I've begun to think perhaps I should split up the enum into 4 types:

1) BOOST_ENUM
2) BOOST_ENUM_COMMENTS
3) BOOST_ENUM_VALUES
4) BOOST_ENUM_COMMENTS_VALUES

1) would only allow you to specify the names for each element in the enum,
e.g.: BOOST_ENUM(Boolean,
    (True)
    (False)
)

2) Let's you specify comments for each element, e.g.:
BOOST_ENUM_COMMENTS(Colors,
    (Red)("Like an apple")
    (Orange)("Like an orange")
)

3) This one I'm still working on, but you should be able to do this:
BOOST_ENUM_VALUES(
    (A)(0x10)
    (B)(0x20)
)

4) This is the most complex one, but you could do:
BOOST_ENUM_COMMENTS_VALUES(
    (A)(0x10)("This is an A")
    (B)(0x20)("This is a B")
)

I was also thinking how neat it would be to let the value portion of an
element be whatever type the user wanted it to be, instead of it just having
to be an integer. Well, this idea is just a muse, not sure if it really can
be done or is even that desirable.

-Frank