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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk