switch statements and boost::enum

[ddurham2]

No description provided.

[ddurham2]

Hi, I've come across your enum implementation for boost. I've used it successfully for a while now. Works well.

However, I ran across an issue where it doesn't seem to make sense...

It has the concept of index() which returns size_t, but I would have expected it to return the actual C enum value. Doing so would have the advantage that switching on its index would allow compilers to warn on unhandled elements from the enum.

I looked at the implementation an noticed that index_type is conveniently defined in enum_base, making it easy to change, and I think all the methods would be fine using an enum instead of a size_t which it is currently defined to.

However, the problem occurs when you try to actually get that typedef to be the Derived class's enum domain {...} type.

I considered both A) just changing the typedef of index_type to "typename Derived::domain" which results in trying to use the Derived type which is not yet fully declared and B) passing that enum type as a template parameter to base_enum. But that results in trying to derive from a templated type, passing it an argument of domain which is not yet declared in the derive class's body.

So, a question: I wasn't sure why enum_base even exists. Its intention, I assume, was so that the two macros that define the derived classes don't have to do much because most of the guts are in the enum_base class.

But the different between the macros (BOOST_ENUM and BOOST_ENUM_VALUES), from what I can see, is just whether you want the value type to be int or something custom.

If my assumptions are correct, and no user would be using enum_base directly, then wouldn't it be fine to have the BOOST_ENUM(_name, _seq) invoke BOOST_ENUM_VALUES(_name, _seq, int) and have BOOST_ENUM_VALUES fully declare the class (not deriving from anything) which would then allow it to typedef index_type to domain.

Make sense?
Foresee any problems? If not, and I'm successful, I'll create a fork and offer a pull request.

Thanks

[ddurham2]

Nevermind on some of that,
never having used BOOST_ENUM() itself, I didn't realize that you don't have to give a value, as it counts them for you. But I think it could be worked out similarly, just not as simple as having one macro call the other.

[ddurham2]

I do have working concept, but it did involve some casting hackery to get iterator to work, since enum values aren't incrementable, but we do know that the enums we're using start with 0 and don't have gaps. And the same assumptions are made by interpreting the domain as a size_t and incrementing that.

Perhaps it would be better to leave everything as is, and just make an accessor for doman enum value and call it a day.