Thanks for your comments Vincente, I'll try to answer to some points.
I don't know if you know my development of Boost.Enums on the sandbox (https://svn.boost.org/svn/boost/sandbox/enums/libs/enums/doc/html/index.html). Were you aware of it?
Yes, as I said, I know that there already are some enum libraries in development at Boost. I didn't know exactly how stable and how active was the development though. My point wasn't to offer another one but to get some comments on my code and on the design choices I took. I've had a quick look at yours, but there were some point refraining me from using it, like stream I/O, no integer implicit conversion.
The library is not stable enough and doesn't takes care of stream I/O yet. Output to a stream is quite simple to add as the library provides enum to string conversion. Input from a stream will be a little more complex in the general case, but quite simple if the associated string doesn't contains white characters. I'm not sure the stream I/O of enums shouldn't use directly the string form. A manipulator could be used to this respect. I need to think about it a little more.
Stream I/O was a very important requirement to me. Initially, I've coded the library to help me reading and writing key mappings from and to a configuration file. The keys were represented by enums, and could be modified with a bit field combination of modifier keys (alt, ctrl, shift...). I did want to have a straightforward conversion from string representation to enum representation. Additionally, when logging enum values, I wanted to have the enum value printed out instead of a obscure integer value. There is a drawback that I've forgotten in my initial mail, my library doesn't support white space in enum values either. As you say, it's much more simpler like this, and seemed an acceptable constraint to me.
I'm not sure the word serialization is the most appropriated in your case, as what you provide is stream I/O. Anyway the library should provide also serialization as defined in Boost.Serialization. I will add this to my to do list.
I'll have a look at what's needed for Boost.Serialization.
IIUC this is an enum that can take only the enum literals, isn't it? If yes, I suggest an alternative name: strong_enum.
Note: My library doesn't provide strong enums.
The names are probably a little bit a matter of taste (although strong enum is maybe better than static), but yes, restricting values to explicitly defined literals is the purpose of this flavor.
IIUC this is a classical enum that allow to store other values than the enum literals. I suggest to call them just enum. The specificity is associated to I/O on streams. I guess that this feature could be orthogonal to the class.
Also right, but I dont think that reusing the name enum is a good idea, it can be confusing with the native one, and "dynamic enums" are not just enums. The allowed values are in a given range, where plain enums can have any value. The specificity is associated with stream I/O, as for "static enums", as in memory, the enum variable can still take any value as the variable isn't anything more than the plain old enum itself. This is maybe not a good idea, and maybe operations should return the "unknown" value, even in-memory, if the given value is not one of the allowed ones. Additionally, when using C++11, the dynamic enums also add +,-,+= and -= operators between enum and integers, that returns an enum value. "Static enums" do only define operators between integer and enums (integer at the left hand side), that works like integer operation and automatically casts the enum value to integer. I'm not sure if it is a good idea to have the operator change its meaning whether the enum is on the lhs or rhs though...
In my library this type should correspond to an enum_set, which offer a safe interface for ordinal enums.
Ok, if enum_set is the name you're using to represent a bit field - where enum literal represent a bit position, this is it.
- No namespace support. I guess this is what the standard call scoped enums, isn't it? My library provides an emulation of scoped enums with some limitations. Some syntactic workarounds need to be used to overcome the limitations.
Scoped enums is what is used for all the flavors. In C++98, the enum is wrapped in a struct, and typedefed at namespace scope to emulate scoped enums, in C++11 enum class are used. There is no way to add enum values to namespace scope, but that was intentional and part of my requirements. What I mean here, is that the enum has to be declared in the global namespace because the macros expands to some template specialization code that will generate an error if not in the same namespace as the template declaration. To enable in-namespace enums here, I would need to know the current namespace, close it, then declare the specializations, and reopen it after. I don't think to be able to do so yet. The other way is not to have template specialization of a template that is not in the same namespace...
The syntax associated to this example
lte_enum(static_enum, lte_ev(value1,2) lte_e(value2) lte_en(value3,"value_number_3"), ::boost::uint8_t )
This is the syntax when using "shortcut" macros, which isn't enabled by default. As in the test files, I've added this functionality to have much shorter macros for the definition, but the names are much less explicit and I think it may be good for writing lighter code, but not good for comprehension. What's more understandable between "lte_en" and "TENUM_ELEMENT_NAMED"?
BOOST_ENUM_TYPE(static_enum,::boost::uint8_t, ( (value1) (2) ) ( (value2) ) ( (value3) () ("value_number_3") )
I don't know if this is more readable to you.
I don't like the overcrowding of parentheses, but that's my personal taste. We aren't doing LISP here, are we? :-)
I was looking for the Jamfile to run the test. I see now that there is a Jamroot file on the root. It would be better to provide a Jamfile for the test directory as the other Boost libraries do. I will try to run it.
The library is meant to be build separately from boost tree. The Jamroot is used as the main build file, and running bjam from the library folder should do the trick (I don't know how this works on windows though...). Best regards, Beren