- Boost - lists.preview.boost.org

[PropertyTree][variant] Reading JSON into a recursive variant.
by Arindam Mukherjee 31 Oct '14

31 Oct '14

I have a recursive variant definition that can handle JSON data. Is there a way to read JSON data using PropertyTree into a recursive JSON? Here is the variant defn. #define BOOST_VARIANT_NO_FULL_RECURSIVE_VARIANT_SUPPORT #include <boost/variant.hpp> JSONNullType {}; boost::variant<std::string, double, bool, JSONNullType> jsonToken; typedef boost::make_recursive_variant< std::string, double, JSONNullType, std::map<std::string, boost::recursive_variant_>, std::vector<boost::recursive_variant_> >::type JSONValue; Regards, Arindam

1 0

Re: [boost] Coming up on 1.57 release date - get your fixes in
by Felix Uhl 30 Oct '14

30 Oct '14

Edward Diener wrote: > Marshall Clow wrote: > > Just this morning we received a report of Boost.PP failing on VS 2013. > > It is not failing. It is just giving a warning. I don’t know for sure, but Marshall may be referring to this ticket: https://svn.boost.org/trac/boost/ticket/10686 On VS2013, VARIADICS and MSVC_VARIADICS don’t get defined despite the fact that they should, rendering some variadic macros useless. Von: Edward Diener Gesendet: ‎Donnerstag‎, ‎30‎. ‎Oktober‎ ‎2014 ‎04‎:‎10 An: boost(a)lists.boost.org On 10/29/2014 10:50 AM, Marshall Clow wrote: > We’ll be closing the master branch tomorrow (Thursday) for the 1.57.0 release. > Changes not in by then will not go into the release. > > Also, what issues in the beta have not been addressed? > >> Visual C++ 14 CTP 4 without BOOST_MSVC_ENABLE_2014_JUN_CTP: all libraries >> built successfully (but some are not usable, mostly because of missing >> noexcept) > >> >> All projects using Boost I tried (Debug 32-bit + 64-bit) compiled >> successfully with MSVC12. For MSVC14, TypeTraits 9de6a49 is missing in >> master. > > I believe that these have been merged. > >> Interprocess is broken for MinGW and there are some issues with Intrusive in GCC. I've committed fixes for both. > > I believe that this has been merged. > > Thread fixes have been merged. > > I do not know if the patches described in http://lists.boost.org/Archives/boost/2014/10/217257.php have been merged. > >> range/detail/any_iterator.hpp is broken because it expects >> postfix_increment_proxy and writable_postfix_increment_proxy to be in >> namespace boost::detail, but they are in boost::iterators::detail now. > > This does NOT appear to have been fixed > >> boost serialization is still broken(said so: http://article.gmane.org/gmane.comp.lib.boost.user/82715 ) and to date i do know no workaround to get my library to work on fx Arch Linux without telling users to rebuild with boost 1.55 (or sending them a saved package from my system…) > > I do not know what the status of this is; but there have been no commits to range/master in October. > > Just this morning we received a report of Boost.PP failing on VS 2013. It is not failing. It is just giving a warning. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

[testing] Compile failures on MSVC (teeks)
by Andrey Semashev 30 Oct '14

30 Oct '14

Hi, I'm seeing weird compilation failures on Teeks (MSVC 10 and 11): http://www.boost.org/development/tests/develop/developer/output/teeks99-08c… http://www.boost.org/development/tests/develop/developer/output/teeks99-08d… The weird part is this: D:\teeks99-08\d\boost_root\boost/fusion/support/detail/result_of.hpp(32) : error C2143: syntax error : missing ',' before '...' I cannot find the boost/fusion/support/detail/result_of.hpp file in git. Am I missing something or these test machines are broken somehow?

2 1

Coming up on 1.57 release date - get your fixes in
by Marshall Clow 30 Oct '14

30 Oct '14

We’ll be closing the master branch tomorrow (Thursday) for the 1.57.0 release. Changes not in by then will not go into the release. Also, what issues in the beta have not been addressed? > Visual C++ 14 CTP 4 without BOOST_MSVC_ENABLE_2014_JUN_CTP: all libraries > built successfully (but some are not usable, mostly because of missing > noexcept) > > All projects using Boost I tried (Debug 32-bit + 64-bit) compiled > successfully with MSVC12. For MSVC14, TypeTraits 9de6a49 is missing in > master. I believe that these have been merged. > Interprocess is broken for MinGW and there are some issues with Intrusive in GCC. I've committed fixes for both. I believe that this has been merged. Thread fixes have been merged. I do not know if the patches described in http://lists.boost.org/Archives/boost/2014/10/217257.php have been merged. > range/detail/any_iterator.hpp is broken because it expects > postfix_increment_proxy and writable_postfix_increment_proxy to be in > namespace boost::detail, but they are in boost::iterators::detail now. This does NOT appear to have been fixed > boost serialization is still broken(said so: http://article.gmane.org/gmane.comp.lib.boost.user/82715 ) and to date i do know no workaround to get my library to work on fx Arch Linux without telling users to rebuild with boost 1.55 (or sending them a saved package from my system…) I do not know what the status of this is; but there have been no commits to range/master in October. Just this morning we received a report of Boost.PP failing on VS 2013. Have I missed any of the beta issues? — Marshall

7 11

[fusion] Broken compilation on MSVC (was: [testing] Compile failures on MSVC (teeks))
by Andrey Semashev 30 Oct '14

30 Oct '14

On Thu, Oct 30, 2014 at 1:28 PM, Andrey Semashev <andrey.semashev(a)gmail.com> wrote: > Hi, > > I'm seeing weird compilation failures on Teeks (MSVC 10 and 11): > > http://www.boost.org/development/tests/develop/developer/output/teeks99-08c… > > http://www.boost.org/development/tests/develop/developer/output/teeks99-08d… > > The weird part is this: > > D:\teeks99-08\d\boost_root\boost/fusion/support/detail/result_of.hpp(32) > : error C2143: syntax error : missing ',' before '...' > > I cannot find the boost/fusion/support/detail/result_of.hpp file in > git. Am I missing something or these test machines are broken somehow? Oh, sorry, I was looking at the master local branch, and it fails on develop. Anyway, the header is there and it is broken for compilers not supporting variadic templates.

1 0

Re: [boost] 1.57.0 beta 1 is now available
by Felix Uhl 30 Oct '14

30 Oct '14

Edward Diener wrote: >John Doré wrote: >> Unfortunately this gives us the warning: >> >> warning C4003: not enough actual parameters for macro 'BOOST_PP_EXPAND_I' > > It is an expected warning from Boost PP, which can be ignored. The VC++ > preprocessor is not a C++ standard conforming preprocessor so it gives > warnings when none are necessary. There is virtually nothing that can be > done against such warnings except to attempt to turn them off completely > within Boost PP code. I will look into doing this but often it is > impossible to do since VC++ often does not honor where the preprocessor > warning actually takes place when an effort is made to eliminate the > warning at that place. Does that mean the regular >#pragma warning(disable : 4003) doesn’t work for pre-processor related warnings?

1 0

1.57.0 beta 1 is now available
by Marshall Clow 30 Oct '14

30 Oct '14

Boost release 1.57.0 beta 1 is now available from SourceForge See http://sourceforge.net/projects/boost/files/boost-binaries/1.57.0.beta.1/ This release contains no new libraries. For details of what's in the release, see http://www.boost.org/users/history/version_1_57_0.html. Note that the links to files on this web page are for the final release - use the SourceForge link above to get the beta files. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team P.S. There are a couple of known problems with this beta: * There are problems building with MSVC 8.0 * There are some problems with range/detail/any_iterator.hpp. These will be fixed before the release.

9 10

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

30 Oct '14

Artyom Tokmakov wrote: > Have you considered X-macro trick? Yes, and I heavily dislike the syntax. I played around with it a bit and it is absolutely not feasible for this use case. My goal is a simple, intuitive and easy to use syntax. With xmacros you’d have to define an enum in a separate file, Which only makes sense for really, really large enumerations.

1 0

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

29 Oct '14

Artyom Tokmakov wrote: >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. And that’s where the problem lies. To enable large numbers of enum values, I’d have to find a solution without using Boost.PP. Without C++ introducing argument number based macro overloading, that is not possible, short of defining my own macro sequences for more than 256 elements, which I would like to avoid. I am still thankful that you asked for this, because it uncovered a huge implementation problem which induces enormous compilation overhead (1 minute for 48 enum values on my laptop). I will do my best to make the library comprehend large enums, but I can’t guarantee anything larger than 256. --- Felix Uhl

2 1

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

[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

[boost.lockfree] spsc_queue preallocated memory block
by Philip Bennefall 25 Oct '14

25 Oct '14

Hi all, I have a feature request for Boost.lockfree (spsc_queue in particular). When using the runtime sized version, could there possibly be a constructor that takes max_size as well as a T* that is then used as the memory buffer? This would remove the need for a specialized allocator if I want to quickly initialize the buffer with memory that does not come from the default std allocator. Kind regards, Philip Bennefall

2 2

Re: [boost] Applying Boost Phoenix to infinite sequence
by Aaron Levy 25 Oct '14

25 Oct '14

25.10.2014, 00:54, "Aaron Levy" <aaron.levy(a)yandex.com>: > Is there a way to use Boost Phoenix to define an infinite sequence and evaluate specific terms of it, compute partial sums, etc? I am looking for pointers to specific libraries or examples. > Indeed, what would are some examples of common programming problems that can be succinctly solved using Phoenix? Aaron.

2 1