Re: [boost] Smart enum

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2006-03-30 16:25:47

Tomas Puverle wrote:
> Thank you for your email.  

You're welcome! This idea is worth commenting on -- I'm sure that such a utility can be broadly useful (I'd certainly like to have it in my toolbox ;-) ).

>>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.
> 

Actually I was not talking about ability to customize things but rather about putting the meta information into templates (so there is no overhead when there are no instantiations). Why write policies for things that can work automatically?

> 
>>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?
> 

The problem I have with "smart" is that it doesn't really say anything...
I actually like "managed" (even though that adjective might sound .NETish).

> 
>>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.

OK - so my code is what you call a "wrapped" enum then, I figure...

>>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.

...and "free" enums can't have member functions, right?

If so, it's a very strong argument against a public member function interface -- maybe even against member functions and wrapped enums (let the user wrap it at will) altogether.

>>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.

BOOST_FOREACH(my_enum) (or BOOST_FOREACH(mpl_sequence_of_constants) for that matter) would be cool... However, this feature would require a detection mechanism to find out whether some tokens represent a type or an expression -- and I don't know if it's implementable without a (native) typeof operator. 

 struct normalize { template<typename T> normalize(T const &); };

 #define IS_TYPE(parenthesized_input) \
   ::boost::is_function< typeof(normalize parenthesized_input) >

 // IS_TYPE((int))::value is true
 // IS_TYPE((1))::value is false

Does anyone know how to implement this without a typeof operator?

4. Another idea: hanlde ORed combinations of enumerators that encode bit patterns (probably even with constraints)...

Regards,

Tobias