Re: [boost] Is there interest in a library for string-convertible enums?

Subject: Re: [boost] Is there interest in a library for string-convertible enums?
From: Felix Uhl (felix.uhl_at_[hidden])
Date: 2014-10-29 06:04:45

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_at_[hidden]





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