Re: [Boost-users] safe assign of int to enum
By defn, static_cast does not provide runtime checks. You should use an enum class or something. Boost needs scoped enums! Anyway, I've used this with varying degrees of success but its not really easy to specialize: #include <cassert> struct MyEnum { enum type { a,b,c, min=a, max=c }; }; 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); } int main() { MyEnum::type b(convert_enum<MyEnum>(0)); // ok MyEnum::type a(convert_enum<MyEnum>(5)); // dies }
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Oliver.Kowalke@infineon.com Sent: Sunday, March 26, 2006 10:42 PM To: boost-users@lists.boost.org Subject: [Boost-users] safe assign of int to enum
Hello, is a technique available in boost in order to assign an int value to a enum?
enum E { e1 = 1, e2 = 2, e3 = 3 };
E e( static_cast< E >( 1) ); // should work
E e( static_cast< E >( 5) ); // should throw exception at runtime
Regards, Oliver _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
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
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@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
I've wasted many hours doing most of these things, so I would be interested in seeing your solution.
Tim, Thanks for the interest. As I said, at this point this is an IP issue and I want to make sure I do everything the right way (my job depends on it ;) I will (hopefully) post more details as soon as soon as I hear back from legal. Tom
participants (4)
-
Sohail Somani -
Tim Robertson -
Tomas Puverle