October 2014 - Boost - lists.preview.boost.org

[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

[Lockfree] has_trivial_destructor and has_trivial_assign restrictions
by Dan Dillon 28 Oct '14

28 Oct '14

I've been doing some thinking about this, and to my untrained eye these restrictions do not seem to be a requirement of the lock-free structure. That is to say, they need not be atomic anyhow, so why does it matter if they are trivial or not? The question goes to making the data structures more globally useful. The more structures they can be used with, the better they are (at least in my opinion). Thanks, Dan

2 1

Custom logging backend difficulty
by Kenneth Adam Miller 28 Oct '14

28 Oct '14

So, I need malleable logging facilities, and so far I've identified boost's logging facilities as useful. I've read the docs on logging, and right now I'm having difficulty achieving what I want-basically, I have a custom backend, in order that when logging is done, it gets routed to an alternative destination - over the network namely. I extended from text_ostream_backend, and basically I'm having the following trouble: I don't understand the record_view visitation API. I'd like the ability to set formatters and what not to remain untouched, but have the final formatted result sent off else where. I can change this by sending the string received in the consume function that has to be overrode, but the values are lost in the record_view. void consume (const record_view & rec, std::string s); where I do { send(s); } for the body. What I think is necessary is just to retain the default behavior of accepting whatever formatter was specified... What is the best way to go about achieving what I want?

3 8

1.57.0 beta 1 is in a new location
by Marshall Clow 27 Oct '14

27 Oct '14

Tom Kent pointed out that I put the beta 1 files in a folder that we traditionally use for Windows binaries, so I have moved the beta files to https://sourceforge.net/projects/boost/files/boost/1.57.0.beta.1/ These are the same files as last Monday - merely in a new location. If you have already downloaded and tested the beta, thanks! - no need to do it again. — Marshall

1 0

Re: [boost] Non-allocating constexpr functional continuations-based future-promise
by Bjorn Reese 26 Oct '14

26 Oct '14

On 10/23/2014 11:00 PM, Niall Douglas wrote: > Given Hartmut's feedback from my previous attempt at a non-allocating > future-promise implementation, I now have a second, much more generic > demonstration prototype which is based on heterogenous sequences of > constexpr functional calls. I think this design may have huge potential. This is a very nice evolution of your previous promise-future framework. > template<class T> struct then_continuation > { > std::vector<std::function<void(T)>> _conts; > template<class U> auto then(U &&c) > { > typedef decltype(c(std::declval<T>())) result_type; > promise<result_type> p; > future<result_type> ret(p.get_future()); > // Unfortunately libstdc++'s std::function currently always tries to > copy lambda types > //_conts.emplace_back([p=std::move(p), c=std::forward<U>(c)](T > v){p.set_value(c(v));}); > _conts.push_back([p = > std::make_shared<promise<result_type>>(std::move(p)), > c=std::forward<U>(c)](T v){p->set_value(c(v));}); > return ret; > } > BOOST_CONSTEXPR T operator()(T v) const > { > for(auto &i : _conts) > i(v); > return v; > } > }; > > All this continuation does is provide a .then(callable) which stores those > callables into a std::vector and its operator() executes the previously > stored callables. Previously you defined callables as composed functions, but here you execute them sequentially. That is, then(f1).then(f2) gets executed as f1(v),f2(v) instead of f2(f1(v)). Or am I missing something?

2 1