Re: [boost] BOOST_ENUM proposal

From: Yuval Ronen (ronen_yuval_at_[hidden])
Date: 2005-12-10 04:41:17

Frank Laub wrote:
>>This looks really nice, especially if you could get the _VALUES version.
>>I'd very much like to see something like that in Boost.
> 
> I'm in the midst of completing this feature.. almost there!  What do you
> think a good name for it is? BOOST_ENUM_VALUES or BOOST_STRINGTABLE or
> something else maybe?

When I say 'the _VALUES version', I mean the version which assign 
numerical values to enum values, so I think BOOST_ENUM_VALUES (in 
addition to BOOST_ENUM with no numerical values) is just fine.

>> I doubt if the storage array needs to be 'size+1' large. The last
>> element of the size itself doesn't need to be stringized.
> 
> The reason I did this is because my preprocessor fu is not strong enough.
> The problem is how to deal with the trailing comma at the end.. my hack is
> to place another 'trailing' field to keep from having syntax errors.

I don't think the comma at the end is a problem. If I'm not mistaken, 
the C++ compiler (not preprocessor) should be able to handle these 
last-commas-with-nothing-after-them. The preprocessor need not deal with it.

>> The size value of the enum type itself can be moved outside to be a
>> 'const size_t size = 2;'. I'm not sure that it really matters, I just
>> think it's more elegant. But of course you can disagree...
> 
> Ya, I could see the size being outside.. but because of my trailing comma
> concern, thought I'd kill two birds with one stone.

Well, if you can solve the comma issue...
And of course the 'size' member should be 'static'. But you probably got 
it yourself...

>> I also think the addition of the 'Invalid' value is not needed. If the
>> enum::type would have been default constructed to 'Invalid', then there
>> might be justification for this. But AFAICS, this is not the case, so
>> IMO it's better removed. The user can always add it himself.
> 
> In all the actualy uses of this thing I've always needed an 'Invalid' field
> which is specifically used for things like default ctors. I can see how some
> users would rather add it themselves.. maybe they're worried about clashes.
> Perhaps there is a way to make the enum type be more than just a class-type
> (or a type with only static members on it). I was toying with an
> instanciable enum type, but I haven't gotten too far with it.

An instanciable enum is a good idea. safe_enum would contain a 
non-static data member of type 'type', a default ctor, a ctor taking 
'type', operator=, etc... This would allow users to write

   Level my_level;

instead of

   Level::type my_level;

which makes your enum more like native enums. I think this will appeal 
to users.

However, I still don't think that an instanciable enum, even with 
default ctor initializing to 'Invalid' justifies the 'Invalid' value. If 
the user wants a not-initialized state, he can always add this value 
himself, or even better, use boost::optional which was created for this 
purpose exactly. No need to burden all users with another value to take 
care for.

>> BTW, the example in your first message showed a 'foreach(...,
>> Level::names)' printing all values including "Invalid", not including
>> the size. Accroding to the implemenation I see here, this seems to be
>> impossible. Or did I miss anything?
> 
> Ah, that was an older version, the current version should print the size at
> the end, minus the Invalid. Good catch!

And even more important then the 'names' array, would be a 'values' 
array which holds the possible values, and can be for_each()ed. I think 
most users would use this array and not the 'names' array... In the 
regular version users can do a 'for (int i = 0; i < Level::size; i++)', 
but with the _VALUES version they must have this 'values' array. I'd 
even say that when you get the 'values' array operatioal, you can move 
the 'names' array to be private. Users have the str() function if they want.

Keep up the good work!
Yuval