Re: [Boost-users] safe assign of int to enum

From: Tim Robertson (timr_at_[hidden])
Date: 2006-03-27 18:45:58

I've wasted many hours doing most of these things, so I would be 
interested in seeing your solution.

At the very least, could you post some information on the approach you 
used to keep the forward/reverse mappings updated automatically?  Also, 
were you able to do all of this without balooning the size of your 
"enums"?  I've never found a way to do that....

-tim

Tomas Puverle wrote:
>>template<typename Enum> 
>>typename Enum::type convert_enum(int a)
>>{
>>	typedef typename Enum::type type_;
>>	assert(a >= Enum::min && a <= Enum::max);
>>	return type_(a);
>>}
> 
> 
> This won't work for enums where the range is not continuous.
> 
> I wrote a library for "smart enums" that allow you to:
> 
> 1)  Keep a forward and reverse mappings between enums and strings (in fact, 
> you can use multiple strings for a single enum value ;) This is done in such a 
> way that you can't fail to update the string table if you add/change an enum 
> and vice versa.
> 2)  Compile time and runtime validity checking (depending on the operation).  
> So for example trying to convert from a string to an enum will be runtime 
> checked but trying to assign a constant to a the enum will be compile time 
> checked.  At the moment I don't have a "intToEnum()" function, which is what 
> you want but that would be trivial to add (5 lines of code or so).
> 3)  Enums can be checked for validity (e.g. unitialised enums are not valid), 
> as well as iterated (even if not a continuous range), strings retrieved, etc.
> 4)  The enum values are still static compile time constants, so you can use 
> them in switch statements etc.
> 5)  There is support for bit manipulation, so you can e.g. unparse a string in 
> the form of (X|Y|Z) into an integer and vice versa
> 6)  It's fast!  There is minimal overhead to all these operations.  The most 
> expensive operation in the library is the conversion from string to enum (a 
> map lookup)
> 7)  There is an automatic enum value called "COUNT" which will give you the 
> value of "last+1".  This is a bit meaningless with bitfields and non-
> contiguous ranges and also given that the enum values can be iterated, but is 
> occasionally useful nonetheless.
> 8)  I tested it with SunCC and gcc.
> 
> Possible improvements I am thinking of:
> 1)  Serialization (from safest to fastest - store the string or a number).  
> This would be trivial.
> 2)  Different underlying types.  At the moment, the enum defaults to being a 
> long, which will be an overkill in a lot of situations.  Again, this would be 
> trivial to add.
> 3)  Maybe support for LuaBind/Boost.Python enums?
> 4)  At the moment, the enum will always live inside its own "namespace", so 
> you have to refer to the values as "MyEnum::ENUM1".  I prefer to encapsulate 
> enums that way instead of having the values spill into the global namespace 
> but I could look into supporting that.
> 5)  I could look into integration with existing enums (e.g. if sharing code 
> with C)
> 
> Would there be interest in such a library?  If so, I will check with our legal 
> if I can post the code (the fun of working for a corporation!)
> 
> Tom
> 
> 
> 
> 
> 
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users