- Boost - lists.boost.org

Is there interest in a library for string-convertible enums?
by Felix Uhl 29 Oct '14

29 Oct '14

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. I’ve written a small header-only library that uses Boost.Preprocessor and templates to ease the definition of named enumerations that are convertible to and from strings. Those can also be used with the std::cin and std::cout streams naturally, while maintaining all syntactic and semantic properties, regarding initialisation, assignment, type safety and conversion to underlying types. Currently, I am documenting the first version of the library to make it available on the Boost Library Incubator website, but I wanted to get some initial feedback from the developers mailing list, too. I would be glad to extend the library to a general extension of enumeration behaviour, like changing the generation of underlying values from a continuous increment to a continuous shift left by one, effectively making the underlying values binary flags. What features would you want from such a library? Is there even a chance that such a library would get included in boost (given that it satisfied the quality requirements), or is there too little interest in this functionality?

8 7

Re: [boost] Is there interest in a library for string-convertible enums?
by Felix Uhl 29 Oct '14

29 Oct '14

Pieter wrote: > Are you aware of the earlier effort by Frank Laub? Frankly (no pun intended), I am not. It would be interesting to see how he has implemented that and what caveats his implementation has. --- Felix

1 0

Re: [boost] Is there interest in a library for string-convertible enums?
by Felix Uhl 29 Oct '14

29 Oct '14

Jeffrey Bush wrote: > I have also offered a class for doing this as well, although it didn't draw > the interest that this one did. > Here was my attempt at it with a test/example class: > https://gist.github.com/coderforlife/6d8bac451d49dd1a0c81 Looks good to me, and seems to be quite close to what I aim at. But the definition seems very user unfriendly. Is it correct that you always have to declare enums in the public namespace? --- Felix

1 0

Re: [boost] Is there interest in a library for string-convertible enums?
by Felix Uhl 29 Oct '14

29 Oct '14

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

1 0

[gsoc] Any interest in Google Code In?
by Niall Douglas 29 Oct '14

29 Oct '14

The application period for Google Code In 2015 has opened. This is a "tiny GSoC" programme for high school students where the tasks set might take the student three to five hours each. Stuff like writing documentation, improving unit testing, duplicating bug reports, making YouTube video tutorials, blogging about or writing an essay about getting a Boost development setup ready, even refactoring small segments of code if the student is up to it. The important part is the shortness of work item, and of course that you review it and give constructive feedback. More detail is at https://developers.google.com/open-source/gci/. Some example tasks from last year are at https://developers.google.com/open-source/gci/resources/example-tasks. Is there any interest from the Boost community in mentoring such high school student work? If so, now is the time to say. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

2 2

Re: [boost] Is there interest in a library for string-convertible enums?
by Artyom Tokmakov 29 Oct '14

29 Oct '14

> What features would you want from such a library? Hello, thanks for the proposal, it's very useful! In addition to various useful suggestions on the list, I would ask for implementation to support (almost) any large number of enum elements (enumerators) within enum declaration.: I have ad-hoc implementation of my own which uses Boost.Proprocessor's sequence to define enum elements. Then I can generate whatever parser/printer/other code I want (I find that very useful). There's a disadvantage, however: obvious limitation of max 256 elements (at least, by default) coming from Boost.Preprocessor. In fact, I hit some other limitations even before that. One of them was max 'if else' statements (I used them in parser implementation. Don't judge me, it was good enough!). When I fixed that, my VC compiler started complaining about some macro processor limitations around 220 enum elements (don't have details handy). Speed of parsing/printing implementation doesn't matter for me. PS: This is my first post in this DL, sorry if I broke some rules. -- Best regards, Artem Tokmakov

1 0

Re: [boost] Is there interest in a library for string-convertible enums?
by Jeffrey Bush 29 Oct '14

29 Oct '14

> > 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. > > > I?ve written a small header-only library that uses Boost.Preprocessor and > templates to ease the definition of named enumerations that are convertible > to and from strings. Those can also be used with the std::cin and std::cout > streams naturally, while maintaining all syntactic and semantic properties, > regarding initialisation, assignment, type safety and conversion to > underlying types. > > > Currently, I am documenting the first version of the library to make it > available on the Boost Library Incubator website, but I wanted to get some > initial feedback from the developers mailing list, too. I would be glad to > extend the library to a general extension of enumeration behaviour, like > changing the generation of underlying values from a continuous increment to > a continuous shift left by one, effectively making the underlying values > binary flags. > > > What features would you want from such a library? Is there even a chance > that such a library would get included in boost (given that it satisfied > the quality requirements), or is there too little interest in this > functionality? > I have also offered a class for doing this as well, although it didn't draw the interest that this one did. Here was my attempt at it with a test/example class: https://gist.github.com/coderforlife/6d8bac451d49dd1a0c81 Supports value to string and string to value, including multiple values with | between them, meaning all combinations can be round-tripped. Supports default power-of-two values and custom values, listing all valid values (as enum types, but each is easily convertible to integral and string values), Although you cannot specify custom string names for an enum value that is not the "STRINGIZE" name, however you can choose to have multiple enum entries with the same value and different names. Jeff

1 0

Re: [boost] Is there interest in a library for string-convertible enums?
by Felix Uhl 28 Oct '14

28 Oct '14

Marcel Raad wrote: >being able to specify the underlying >type, not being implicitly convertible >to any other type, and being able to >forward-declare them. Apart from forward-declaration, that’s what I’ve implemented. I want to stay as close to the stock enum class as possible. Forward declaration is added to the feature list :) --- Felix Uhl

1 0

Re: [boost] Is there interest in a library for string-convertible enums?
by Felix Uhl 28 Oct '14

28 Oct '14

On 28/10/2014, Rob Stewart wrote: >That sounds interesting. Ease of use and compilation overhead are concerns, of course. I’ll answer your ease of use concern with example code for definition of the enum class Zott: >BOOST_ADVANCED_ENUM_DEFINE( Zott, > zero, > one, > two, > three >); And now for the mentioned “flag” values: >BOOST_ADVANCED_ENUM_DEFINE_W_SUPPLY( > TwoToThePowerOf, > ::boost::advanced_enum::supplies:shiftL1::values, > zero, > one, > two, > three >); Seems easy enough. The second one could be shortened to another macro, of course. Arbitrary values have a bit strange syntax, though: >BOOST_ADVANCED_ENUM_DEFINE_W_SUPPLY( > BOOST_ADCANCED_ENUM_ARBITRARY(4, 8, 6, 20), > four, > eight, > six, > twenty >); I’ll see what I can do about that. Conversions to and from string are done via static_cast (not sure if that’s the ideal solution), in- and output work naturally like this: >Zott myZott = Zott:one; >std::cin >> myZott; //if input is not convertible, no changes are made >std::cout << myZott; I think that's as easy as it can get :) Compilation overhead indeed needs to be considered. >What about enum classes? My mistake, with “named enums” I meant “enum classes”, but now that you say it, I should try to implement string convertible regular enums as well. Thank you for your feedback! --- Felix Uhl Von: Rob Stewart Gesendet: ‎Dienstag‎, ‎28‎. ‎Oktober‎ ‎2014 ‎22‎:‎23 An: boost(a)lists.boost.org On October 28, 2014 7:09:35 AM EDT, Felix Uhl <felix.uhl(a)outlook.de> 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. As Niall noted, most of us have done that before. >I’ve written a small header-only library that uses Boost.Preprocessor >and templates to ease the definition of named enumerations that are >convertible to and from strings. That sounds interesting. Ease of use and compilation overhead are concerns, of course. >Currently, I am documenting the first version of the library to make it >available on the Boost Library Incubator website, I can hear Robert yelling, "Yes!" > but I wanted to get >some initial feedback from the developers mailing list, too. I would be >glad to extend the library to a general extension of enumeration >behaviour, like changing the generation of underlying values from a >continuous increment to a continuous shift left by one, effectively >making the underlying values binary flags. That would certainly be useful. What about enum classes? ___ Rob (Sent from my portable computation engine) _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: [boost] Is there interest in a library for string-convertible enums?
by Felix Uhl 28 Oct '14

28 Oct '14

On 08/10/2014, Damien Buhl wrote: >What I would like to is to have a complete adapted enum for >Boost.Fusion, this was implemented at some point in some old version of >Boost.Fusion but I cannot find it anymore. Yes, interoperability with other boost libraries is a huge point to consider, and I like the concepts of Boost.Fusion a lot. I also thought about MPL, getting the names as compile time strings could be really useful. >And before all it's important I believe that it doesn't ask the user to >write the enums with macros, but that an additional call later to >something like BOOST_ADAPT_ENUM adds the boilerplate code. >It's naturally possible to offer both choice to the user like >BOOST_FUSION_ADAPT_STRUCT / BOOST_FUSION_DEFINE_STRUCT. I don’t think it is possible to offer an ADAPT_STRUCT macro without forcing the client to either rewrite every single value of the enumeration or define the enum with another macro in the first place. The former would could become problematic when clients change what values the enum actually contains but forget to change that in the macro. I would really want to enable the most natural syntax possible, but even a flexible language like C++ has boundaries where you can’t bend it anymore. So yes, I will offer both to the user. Thanks for your feedback! Felix Uhl Von: Damien Buhl Gesendet: ‎Dienstag‎, ‎28‎. ‎Oktober‎ ‎2014 ‎22‎:‎47 An: boost(a)lists.boost.org Hi Felix, Personally I'm interested, because so far I've been always using a silly macro for this, which doesn't make much : > #ifndef SWISSARMYKNIFE_ENUMS_ADAPT_ENUM_HPP > #define SWISSARMYKNIFE_ENUMS_ADAPT_ENUM_HPP > > #include <string> > #include <ostream> > #include <boost/preprocessor/cat.hpp> > #include <boost/preprocessor/stringize.hpp> > #include <boost/preprocessor/seq/for_each.hpp> > > > #define SWISSARMYKNIFE_ADAPT_ENUM_EACH_ENUMERATION_ENTRY_C( \ > R, unused, ENUMERATION_ENTRY) \ > case ENUMERATION_ENTRY: \ > return BOOST_PP_STRINGIZE(ENUMERATION_ENTRY); \ > break; > > #define SWISSARMYKNIFE_ADAPT_ENUM(ENUM_TYPE, ENUMERATION_SEQ) \ > inline std::string to_string(const ENUM_TYPE& enum_value) { \ > switch (enum_value) { \ > BOOST_PP_SEQ_FOR_EACH( \ > SWISSARMYKNIFE_ADAPT_ENUM_EACH_ENUMERATION_ENTRY_C, \ > unused, ENUMERATION_SEQ) \ > default: \ > return BOOST_PP_STRINGIZE(ENUM_TYPE); \ > } \ > } \ > \ > inline std::ostream& operator<<(std::ostream& os, const ENUM_TYPE& value) { \ > os << to_string(value); \ > return os; \ > } > > #endif What I would like to is to have a complete adapted enum for Boost.Fusion, this was implemented at some point in some old version of Boost.Fusion but I cannot find it anymore. Because if this had the extension struct_member_name or some other better named extension, then I could print out all the possible states with some generic code like I print struct member name with "boost::fusion::for_each_member(enumValue, *this);" > #ifndef BOOST_FUSION_FOR_EACH_MEMBER_HPP > #define BOOST_FUSION_FOR_EACH_MEMBER_HPP > > #include <functional> > > #include <boost/fusion/include/adapt_struct.hpp> > > #include <boost/fusion/sequence/intrinsic/begin.hpp> > #include <boost/fusion/sequence/intrinsic/end.hpp> > #include <boost/fusion/sequence/intrinsic/front.hpp> > #include <boost/fusion/iterator/equal_to.hpp> > #include <boost/fusion/iterator/next.hpp> > #include <boost/fusion/iterator/deref.hpp> > #include <boost/fusion/iterator/distance.hpp> > #include <boost/fusion/support/category_of.hpp> > #include <boost/mpl/bool.hpp> > > namespace boost { namespace fusion { > > namespace detail { > > template <typename First, typename Last, typename F> > inline void > for_each_member_linear(First const& first, > Last const& last, > F const& f, > boost::mpl::true_) {} > > template <typename First, typename Last, typename F> > inline void > for_each_member_linear(First const& first, > Last const& last, > F const& f, > boost::mpl::false_) { > > f( > extension::struct_member_name< > typename First::seq_type, First::index::value > >::call(), > *first > ); > > for_each_member_linear( > next(first), > last, > f, > result_of::equal_to< typename result_of::next<First>::type, Last>() > ); > } > > template <typename Sequence, typename F> > inline void > for_each_member(Sequence& seq, F const& f) { > > detail::for_each_member_linear( > fusion::begin(seq), > fusion::end(seq), > f, > result_of::equal_to< > typename result_of::begin<Sequence>::type, > typename result_of::end<Sequence>::type>() > ); > } > > } > > template <typename Sequence, typename F> > inline void > for_each_member(Sequence& seq, F f) { > detail::for_each_member(seq, f); > } > > }} > > #endif And before all it's important I believe that it doesn't ask the user to write the enums with macros, but that an additional call later to something like BOOST_ADAPT_ENUM adds the boilerplate code. It's naturally possible to offer both choice to the user like BOOST_FUSION_ADAPT_STRUCT / BOOST_FUSION_DEFINE_STRUCT. Cheers, -- Damien Buhl On 10/28/2014 12:09 PM, 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. > > > Iâ€™ve written a small header-only library that uses Boost.Preprocessor and templates to ease the definition of named enumerations that are convertible to and from strings. Those can also be used with the std::cin and std::cout streams naturally, while maintaining all syntactic and semantic properties, regarding initialisation, assignment, type safety and conversion to underlying types. > > > Currently, I am documenting the first version of the library to make it available on the Boost Library Incubator website, but I wanted to get some initial feedback from the developers mailing list, too. I would be glad to extend the library to a general extension of enumeration behaviour, like changing the generation of underlying values from a continuous increment to a continuous shift left by one, effectively making the underlying values binary flags. > > > What features would you want from such a library? Is there even a chance that such a library would get included in boost (given that it satisfied the quality requirements), or is there too little interest in this functionality? > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0