Sebastien Martel wrote:

Is there a way to integrate a solution to this problem :

[google groups] http://tinyurl.com/dtnx3

-seb

Yes, that's actually enumerator-specific methods are what for. Here is an example how it can be done with my library. class part_of_speech_policy { public: class base_enumerator { public: virtual const char *get_encoding() const = 0; }; class coordinating_conjunction: public base_enumerator { public: const char *get_encoding() const { return "CC"; } }; class cardinal_number: public base_enumerator { public: const char *get_encoding() const { return "CD"; } }; class determiner: public base_enumerator { public: const char *get_encoding() const { return "DT"; } }; typedef boost::mpl::vector< coordinating_conjunction , cardinal_number , determiner > enumerators; }; typedef boost::enumeration< part_of_speech_policy > part_of_speech; // somewhere in other place BOOST_STATIC_ASSERT( part_of_speech::size == 3 ); part_of_speech foo = part_of_speech::coordinating_conjunction(); BOOST_CHECK_EQUAL( foo->get_encoding(), "CC" ); Hope it does what you expected. Sincerely yours, Maksym Motornyy.

Something similar has been proposed on the MPL to do list:

http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?MPL_TODO_List

search for "don't work with enumeration types:"

Since enumerators in my library are plain classes there is no problem to use them with MPL. Even more, mpl::vector is used to define their sequence order (policy::enumerators typedef).

in range_all.zip. If your enumerators can be used to make tuples or variants with "named" fields, as done in the:

cppljevans/tuple_nested_enum_test.cpp

in the vault, I'd be interested.

I can't swear I understand what is your goal. The test code is a bit hard to read. Could you explain, please? Sincerely yours, Maksym Motornyy.

http://groups-beta.google.com/group/comp.std.c++/msg/7d7d19cf16333d0b?hl=en

The main reason why it was hard to read your code is my lack of knowledge what are you trying to implement. This link clarifies a lot. Second, I wonder why somebody wants to have named fields in tuples? Isn't tuples designed to be anonymous inline-declarable structs? Otherwise it's better to use plain struct's (of course I can be wrong). Sincerely yours, Maksym Motornyy.

From: Maksym Motornyy <mmotorny@yandex.ru>

...

I think that the names are only "meaningful" if the source language and the application user's language are the same. In general this kind of ability is useful in debugging but in real applications the restraints on identifiers is too limiting (i.e. no punctuation, no accents, no spaces). Far more powerful would be the ability to associate arbitrary data with an enum. This I believe is relatively easy to add to your framework.

Yes, mainly the "meaningful" names can be used for debugging and logging. As I wrote in above reply to Sebastien Martel, arbitary data can be added by means of enumerator-specific methods.

We write real applications, but we don't need i18n support in them as they are for internal use. We have a better enum mechanism, though it relies on macros to generate the necessary code. Though that mechanism, we frequently turn enumerators into strings (in both long and short forms) and turn strings into enumerators.

...

I wish to state for the record, I believe macros should only be used as a last resort.

Here's our syntax: SA_BEGIN_ENUM(example) enumerator1[ = expression], enumerator2[ = expression], ... enumeratorN[ = expression] SA_END_ENUM(example) The result is, effectively: class example { public: enum value { enumerator1[ = expression], enumerator2[ = expression], ... enumeratorN[ = expression] }; example() { } example(value value_i) : value_(value_i) { } operator value() const { return value_; } std::string to_string(bool verbose_i = false) const { return map_s.get_name(value_, verbose_i); } static example from_string(std::string const & name_i, example not_found_i) { return static_cast<value>(map_s.get_value(name_i, not_found_i)); } static example from_string(std::string const & name_i) // throws an exception { return static_cast<value>(map_s.get_value(name_i)); } static void dump() { map_s.dump(); } // define various operators private: static ::saol::details::enum_name_mapper map_s; value value_; public: static void register_enumerators(); }; template <typename Stream> Stream & operator <<(Stream & stream_io, example value_i) { return stream_io << value_i.to_string(); } To set the names, we use SA_BEGIN_ENUMERATOR_REGISTRATION(example) SA_REGISTER_ENUMERATOR(enumerator1, "Some long description") SA_REGISTER_SIMPLE_ENUMERATOR(enumerator1) ... SA_END_ENUMERATOR_REGISTRATION(example) SA_REGISTER_ENUMERATOR registers the enumerator name converted to a string (preprocessor stringizing) plus the long description as the non-verbose and verbose forms, respectively. SA_REGISTER_SIMPLE_ENUMERATOR registers the enumerator name as both the long and short forms.

Absolutely agree. If you find "meaningful" names not very useful feature, enumerator definition can be done without macros.

We use that regularly. Since the macros generate typesafe code, we don't find their use problematic. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;