Re: [boost] Smart enum

From: Tomas Puverle (Tomas.Puverle_at_[hidden])
Date: 2006-03-29 12:36:36

Tobias,

Thank you for your email.  Please see my comments inline.

> 1. only the meta information that is really used should end up in the 
executable
>    (can be done via template instantiations)

I am in the process of completely rewriting the library to make it more boost-
like, as well as adding some of the features on my wish list and to make it 
more robust and configurable.  
The idea is to do what you describe.  The enum is policy driven and allows you 
configure the features you want/need.  For example, you can disable/enable the 
string to enum functionality, configure the internal representation etc.

> 2. use a more intuitive name than "smart enum" 
>    something like "reflective enum" or so

I quite like the name "smart_enum" but if there is a negative response to the 
name I will change it.  I hope you don't mind me saying so but I don't 
like "reflective_enum" much.  Perhaps we can find a compromise?

> 3. the implementation should store the values in a structure like that
> 
>     struct enum_name
>     { 
>        enum type { [... values ...] };
>     private:
>        // [...friend declaration & accessors for meta information...]
>     };

This is exactly what my original implementation did as I prefer that practice, 
too.  However, I realised that there are people out there that would perhaps 
like to use this facility but don't want to/can't to go throught all of their 
code and change all of the uses of unqualified enum names to qualified ones.  
My rewrite provides a facility to create both "free" and "wrapped" enums.

> 3.1. the storage type should be a real enum

Yes, unless the user specifies otherwise.  The user can override the base size 
of the enum, to e.g. facilitate binary compatibility between shared libraries. 
(but this is compile time checked to ensure values will fit).  In some rare 
cases, if using some of the features of the enum you may also end up with an 
integer larger than the one needed just to hold the enum values but again, 
this is all user controled.  The basic point is that the internal 
representation is always just an integer.  In fact, you can configure the enum 
to actually use storage smaller than may be required to store the actual 
enum ;)  Probably not very useful but the feature just kind of falls out of 
the design so I allow you to enable it.

> 3.2. its name should be "type" so the enclosing structure can act as a 
metafunction 

Yes, the internal name is called type.
But I have more than that.  You can e.g. use the enum as an mpl bidirectional 
sequence, so you can traverse it at compile time.

> 3.3. no public members, access is implemented via freestanding functions

There are some public members which I believe are generally useful.  I thought 
about this and was undecided between the two approaches: members of free 
functions? In the end I decided on providing both.  You can then take your 
pick.

Thanks for the suggestions.  I should be able to post something soon.

Tom