On 29/10/2014 23:04, Felix Uhl wrote:
Gavin Lambert wrote:
- can round-trip (enum -> string -> enum) values that are not members of the enumeration; of course (string -> enum -> string) is not feasible for non-members.
What would a conversion from an enum that is not a member to a string look like? Should it just be converted to the string representation of the underlying type like “7”? Or something like “MyEnum::7”?
Dealer's choice. IIRC my implementation rendered it to "#7".
Or would the string representation solve a term with bitwise OR like
so: “one|two|four”? The latter would be very interesting for bitwise flag enums.
Only if it's explicitly marked in some way as a bitwise enum. Otherwise it would be more confusing than helpful.
- can specify a custom string value that the enum value generates (not just the BOOST_PP_STRINGIZE).
Yeah I will implement that. Not sure why one would want it, it does nothing but induce confusion in my eyes, but I’m not the one to tell you what to do.
There are a couple of different reasons why this has been useful: 1. Language interop. When used for data interchange serialisation, different languages may have different naming conventions. eg. C# might have an enum value called "Rectangle" but C++ would have it called "SHPT_RECT". 2. Abbreviation, and the reverse (for diagnostics or other display-to-user cases). Sometimes the code has a long expressive name but it needs to be displayed somewhere where a shorter name is needed due to space constraints. Other times, the code has a cryptic name like the above but it needs to be displayed somewhere in a more human-readable form.
- enum to string and back for "bitwise flag" style enums (eg. CSV names).
Not sure what you mean by that, because the regular string conversions work for those just as fine. Do you mean what I wrote above with the OR connected values in a string representation?
Yes, although I was thinking of comma-separated, as C# bitwise enums do it.
- can specify multiple string values that map to the same enum value.
Hm. I’m not sure if I’d want that, or how that could even be implemented.
If somebody wanted non-casesensitive behaviour, it would be better to use a std::string with custom char_traits, and that’s something I’ll definitely offer.
I wasn't thinking of case sensitivity, but again of interop and serialisation. Maybe in an older version of an application something was saved as "Rect" but in the current version it's saved as "Rectangle". It would be nice if it could load both versions successfully, but they map to the same value. Similarly, maybe a C# client could send one string and a C++ client send another. Obviously in the enum -> string direction only one of these would "win" (selected by the developer somehow, eg. the first listed). Another (more complex) case evolves with bitwise enums; perhaps instead of rendering "Foo|Bar|Baz" it should render "All", or instead of rendering "Frob1|Frob2|Frob3|Foo2" it should render "AllFrob|Foo2", where someone has defined named aliases for certain combinations. On 30/10/2014 07:45, Rob Stewart wrote:
You should not add features because someone on this list asked for them. If you're not convinced of the utility of something, push back to understand the request better.
Of course. I was just offering suggestions based on things that have come up when using my own version, since they were being solicited. It's naturally up to the library author to decide which of these make sense for their particular vision of the library or its intended usage.