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 15:14:50

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.




This sounds like advice I should follow. I tend to forget that I’m not writing

for a specific client. Also, I noticed that the library has too much compile 

time overhead already, which should be fixed before introducing any 

additional ground-breaking features.




So I’ve gone through the features suggested and ordered them by priority,

perhaps the requesters of the following ones could answer my questions

about them and specify why they think these features would be a good 

addition to the library:


By Damien Buhl:


 - Adaptation of enums after declaration with something like BOOST_ADAPT_ENUM

Is this really worth the effort?

If somebody knows they want to string-convert an enum (or enum class),

why would they not define it as one in the first place? Or is this about

enumerations that are already defined by other libraries? Would it be

ok to instead define a new enum that has the “to adapted” one as its underlying

type and can thus be converted to and from it?

There are implementational problems with offering both namespace independent

definition of those enums and adaptability.


By Gavin Lambert:


 - Specify custom and multiple strings

In which use cases would this actually be beneficial for anyone?

Could those use cases be solved by using custom char_traits or

even custom string classes?




 - Specify different conversion tables for use in different contexts

What do you exactly mean by that? Conversion to different string values?

Conversion by different algorithms?






Again, if you could answer those questions, it would really help evaluation.


---

Felix