Daniel James wrote:
2009/3/6 vicente.botet <vicente.botet@wanadoo.fr>:
I don't think there is a better solution. You need to mask the fact that a enum type in C++0x is name scope and a type and can not be in C++03.
A class is a name scope and a type - isn't that why it's called 'enum class'?
class algae { public: enum value {green, red, cyan};
algae() {} algae(value v) : v_(v) {}
// And any other required methods... private: value v_; };
algae x = algae::red; algae y = red; // error...
This would also be closer to 'enum class' as it's strongly typed.
Beman's preprocessing syntax would have to change, as the closing macro would have to know the name. The syntax using a preprocessor sequence or varargs would be the same.
I've worked a little bit with the class approach and it has a main portability issue. The use of user constructors disallows the use of the wrapper class in union (c++98 compilers), isn't it? If we don't have the conversion constructor. The following will fail at compile time algae x = algae::red; The same problem with a function returning the wrapper algae f() { return algae::red; } So either the class is not used on unions, either you will need to explicit conversion between the underlying enum type and the wrapper type. algae x = convert_to<algae>(algae::red); algae f() { return convert_to<algae>(algae::red); } I think that even if we need to use a macro to name the enum class type when writing portable code, the namespace approach seems to have less limitations. This doesn't mean that the class approach is not useful if you don't need to include the enum in a union or you work with compilers that allow already that even when there are user constructors (c++0x). But clearly, the approach can not be generalized to Boost, as Boost must be portable. Or, could it? Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/C-0x-Emulation-of-scoped-enums-tp2661312p... Sent from the Boost - Dev mailing list archive at Nabble.com.