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

From: Tomas Puverle (Tomas.Puverle_at_[hidden])
Date: 2006-03-27 15:06:53

> 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