Subject: Re: [boost] Is there interest in a library for string-convertible enums?
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2014-11-04 22:13:09
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
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
>> - 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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk