Re: [boost] Is there interest in a library for string-convertible enums?
Gavin Lambert wrote:
Features that I would expect of such a library:
- support for arbitrary non-contiguous values. - enum value to string. - string to enum value.
That's done already.
- list of all valid values, either as strings or values. - can indicate whether a given value (string or enum) is a member of the enumeration.
Easy, will do.
- 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”? 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.
- 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.
Features that would be nice, but not necessarily expected:
- 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?
- some mapping to std::bitset or similar.
That would be interesting! I’ve added it to the feature list, but it will probably take some time .
- 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.
- can specify different conversion tables for the same enum type (for use in different contexts, eg. serialisation vs. user output).
I thought about that, too. I already give the option to choose between std::maps and a linear search for lookups, but I would really like to give the client more options. Those were good suggestions, thank you very much! You’ve given me quite some things to work on, but now I’ve got a pretty decent feature list. --- Felix Uhl Von: Gavin Lambert Gesendet: Mittwoch, 29. Oktober 2014 00:57 An: boost@lists.boost.org On 29/10/2014 00:09, Felix Uhl wrote:
So far, the only way to convert an enumeration value to a string is a lot of boilerplate code consisting of switch case statements for every single possible value of the enum.
Not the only way. The method I use is to create a lookup table via a little macro magic. Granted that I'm then doing a linear scan through the table (whereas a switch statement could be more efficient, or knowledge that the enum is contiguous and could therefore do an index lookup), but having a table allows for other useful queries, and I wanted something that could be defined statically. As a side-benefit (that undoubtedly will horrify some people), the way the code was implemented also allows it to act as a string-to-member-pointer lookup table, which can be quite handy for typed property bags and the like with a string lookup key.
What features would you want from such a library?
Features that I would expect of such a library: - support for arbitrary non-contiguous values. - enum value to string. - string to enum value. - list of all valid values, either as strings or values. - can indicate whether a given value (string or enum) is a member of the enumeration. - 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. - can specify a custom string value that the enum value generates (not just the BOOST_PP_STRINGIZE). Features that would be nice, but not necessarily expected: - enum to string and back for "bitwise flag" style enums (eg. CSV names). - some mapping to std::bitset or similar. - can specify multiple string values that map to the same enum value. - can specify different conversion tables for the same enum type (for use in different contexts, eg. serialisation vs. user output). _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On October 29, 2014 6:04:45 AM EDT, Felix Uhl <felix.uhl@outlook.de> wrote:
Gavin Lambert wrote:
- 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.
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.
- 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.
I presume there can be multiple enumerators with the same value, so I, too, wonder about this request.
You’ve given me quite some things to work on, but now I’ve got a pretty decent feature list.
I wonder what the overhead of all of that will be on terms of compilation time and resources, runtime behavior, and memory usage. If you make the library too heavy, few will use it. ___ Rob (Sent from my portable computation engine)
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.
participants (3)
-
Felix Uhl -
Gavin Lambert -
Rob Stewart