Vicente Botet <vicente.botet@wanadoo.fr> writes:
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.
This is the approach I've used; I much prefer it to the namespace-based approach.
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?
Yes, but how often do you use unions? I very rarely use unions at all.
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.
Having to use a macro whenever I mention the type name defeats the purpose of using scoped enums --- I might as well write algae::type if I have to write BOOST_SCOPED_ENUM(algae) Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976