January 2015 - Boost-users - lists.boost.org

[mpl] lazy condition in enable_if
by Sam Fisher 28 Jan '15

28 Jan '15

Hi, I need to run boost::mpl::for_each<> function with template condition, like: boost::mpl::for_each< vector_of_types, boost::mpl::make_identity<boost::mpl::_1> > (Functor< condition >()); I'm trying to implement lazy binding in enable_if. Visual studio fails with error "'X<IsFoo<boost::mpl::_>>::operator ()' : ambiguous call to overloaded function" minimal test code which fail on boost 1.57 #include <boost/mpl/for_each.hpp> #include <boost/mpl/lambda.hpp> #include <boost/mpl/bind.hpp> #include <boost/mpl/vector.hpp> #include <boost/core/enable_if.hpp> #include <iostream> #include <type_traits> template <int> struct dummy { dummy(int) {} }; // from doc struct Foo {}; struct Bar {}; template <typename T> struct IsFoo { typedef typename std::is_same<T, Foo>::type type; }; #define generate_type(_fn) \ typename boost::mpl::apply<boost::mpl::bind< \ boost::mpl::lambda< _fn <boost::mpl::_> >::type, \ boost::mpl::bind<typename boost::mpl::lambda<_Pred>::type, U> \ > >::type #define enable_type generate_type(boost::enable_if) #define disable_type generate_type(boost::disable_if) template <typename _Pred> struct X { template <typename U> enable_type operator()(boost::mpl::identity<U>, dummy<0> = 0) const { std::cout << "enable: " << typeid(U).name() << std::endl; } template <typename U> disable_type operator()(boost::mpl::identity<U>, dummy<1> = 0) const { std::cout << "disable: " << typeid(U).name() << std::endl; } }; int main() { X<IsFoo<boost::mpl::_> > x; x(boost::mpl::identity<Foo>()); x(boost::mpl::identity<Bar>()); return 0; }

1 0

[release] Release schedule changes..
by Rene Rivera 27 Jan '15

27 Jan '15

After some discussion in the Boost Release Team we've decided on an ongoing schedule for releases. Taking into account the realities of how long it takes for authors and the release team to work on a release we've decided to move to *three* releases a year. The targets for the releases will now be: * Spring release on the second Wednesday of April. * Summer release on the second Wednesday of August. * Fall/Winter release on the second Wednesday of December. There will be no January release. This will allow for the fact that most people are on extended holidays during Winter. It will also allow for people to work on larger changes that require more testing time during the longer Winter period. We are also moving to Wednesday release to allow the release managers non-weekend time to work before and after the release. Please consult the Boost calendar for specific dates and merge schedule for the next release. Thanks, the Boost Release Team. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

1 0

[multi state machine/ MSM] execute_queued_events
by Steve Hickman 26 Jan '15

26 Jan '15

In the MSM doc section "Enqueueing events for later processing", you state that "Calling execute_queued_events() will then process all enqueued events (in FIFO order)." You also said in a previous post that MSM is not thread safe, thus requiring an external mechanism to insure thread safety. I don't see a mechanism to execute a single event at a time, which would be preferable if I have to lock the queue while processing events. Having said that, a cursory examination of the "execute_queued_events" code makes me think it only processes one event per call. Which is correct? Is the documentation correct that it actually processes all queued events? If not, can the documentation be corrected? If so, is there a publicly usable call to process a single queued event? If there is no publicly available call for processing a single queued event, how do you recommend processing queued events in a thread safe manner that won't lock the queue for extended periods of time?

4 7

[multi_index] recursive declaration of MIC with a value which contains references of its kind
by Nick Stokes 26 Jan '15

26 Jan '15

I have a value type (Foo) which is supposed to contain references to some multi_index_container of its type, like so: struct Foo { int property1; int property2; FooMIC* other; // this (the pointer value) may or may not be indexed upon }; typedef multi_index_container< Foo, indexed_by < sequenced<> , ordered_unique< member<Foo, int, &Foo::property1> > , ... >> FooMIC; Due to recursive nature of this, I wasn't able to figure out how do declare such a thing (other than unsafely using void* references in Foo). Any ideas? Thanks many, Nick

2 2

Re: [Boost-users] [boost] [Review] Boost.Endian mini-review
by Beman Dawes 26 Jan '15

26 Jan '15

On Sun, Jan 25, 2015 at 6:12 PM, Jason Newton <nevion(a)gmail.com> wrote: > On Sun, Jan 25, 2015 at 8:21 AM, Beman Dawes <bdawes(a)acm.org> wrote: > >> On Sat, Jan 24, 2015 at 2:25 AM, Jason Newton <nevion(a)gmail.com> wrote: >> > I think the only thing that I have no interest in using - a kind way of >> > saying its probably unneeded bloat IMO is the arithmetic types. I prefer >> > native types and using conversion functions. But maybe they could >> improve >> > my code - its something I toss back and forth a little and haven't >> > attempted embracing. >> >> Because even the endian buffer and arithmetic types that appear most >> expensive generate only short sequences of code, the optimizing >> compilers often generate exactly the same instructions regardless of >> endian approach. On Intel machines, that often distills down to a >> single bswap instruction since the value is already in a register. >> >> That isn't always true, so you do need to measure performance of >> various approaches in the context of your actual application. But if >> use of the buffer or arithmetic types would otherwise improve your >> code, please don't reject them without actually testing performance >> first. >> > > Allow me to clarify: I meant code bloat, not speed. Sorry - your original post was clear, but I misinterpreted. I have not systematically measured code bloat. Maybe I can do that at least for some common use cases. Thanks, --Beman

1 0

Re: [Boost-users] [boost] [Review] Boost.Endian mini-review
by Beman Dawes 25 Jan '15

25 Jan '15

On Sat, Jan 24, 2015 at 2:25 AM, Jason Newton <nevion(a)gmail.com> wrote: ... > As a long time user of the Boost.Endian library (applying patches to the > distribution I maintain), I am happy to see it finally up for uh... > mini-review. Hoping to see it get to formal review and included... further > hoping it makes it into the next C++ standard! The library went through formal review in 2011, so will go into Boost as soon as the mini-review is over. And, yes, I do plan to propose it to the standards committee. > It is ready in my opinion. I've seen it go through some topical changes > over the years but the only thing I've used from it are the conversion > functions which have been great for implementing proper io in the range of > network socket io / serial with various protocols and stored data from > varies devices/sensors) if a specification enforces byte order. It > fullfills my needs and always did fairly well on performance with gcc/clang. Depending on what version you have been using, the performance may now be even better. > I think the only thing that I have no interest in using - a kind way of > saying its probably unneeded bloat IMO is the arithmetic types. I prefer > native types and using conversion functions. But maybe they could improve > my code - its something I toss back and forth a little and haven't > attempted embracing. Because even the endian buffer and arithmetic types that appear most expensive generate only short sequences of code, the optimizing compilers often generate exactly the same instructions regardless of endian approach. On Intel machines, that often distills down to a single bswap instruction since the value is already in a register. That isn't always true, so you do need to measure performance of various approaches in the context of your actual application. But if use of the buffer or arithmetic types would otherwise improve your code, please don't reject them without actually testing performance first. > > This library should not be looked at as fulfilling an uncommon need - and > should even be part of future C++ standards because the usual > macro/functions (e.g. htons) in the in arpa/inet.h are widely used outside > of inet related code (see above examples) and have the types encoded in the > name making them not easily usable/composable in contrast to something > template based which the library offers. Further IEEE 754 support - > especially for double floating point types. The library definitely fills > that gap and has for years IMO. Thanks for the kind words! --Beman

1 0

[thread] await hangs when using boost::promise/future
by TONGARI J 25 Jan '15

25 Jan '15

Hi, The sample code is here: https://gist.github.com/jamboree/3b8716ad1922749e77ae The boost::future adaption code is adapted from N4286. Tested with VS2015 preview. If std::promise is passed, the code works fine. Any clue why it hangs if boost::promise is passed? Thanks.

3 10

[Graph] source vertex colour at start of BFS or DFS
by Jeremy Murphy 24 Jan '15

24 Jan '15

Hi, I'm wondering, why do the BFS and DFS algorithms not inspect the colour of the source vertices given to them? If a source vertex is already black, shouldn't the search effectively be a no-op? Currently the source vertex is 'discovered' and coloured grey regardless of its previous colour. I know it might seem weird to pass a black vertex as the source, but I guess I see it as similar to passing an empty range to an algorithm: it's valid but nothing happens. Thanks, cheers. Jeremy

1 0

Re: [Boost-users] unit test BOOST_CHECK_CLOSE absolute
by Dave Gomboc 24 Jan '15

24 Jan '15

Gennadiy Rozental <rogeeff <at> gmail.com> writes: > > Paul A. Bristow <pbristow <at> hetp.u-net.com> writes: > > FWIW I've also wanted the *values* in a message (rather > > than just a test fail). > > I do not follow this comment. Which message and which tool do you refer to? Perhaps he meant that he'd like the error message when a BOOST_CHECK_CLOSE fails to show the value that was rejected, and also the range of values that would have been accepted? Dave

2 1

[Review] Boost.Endian mini-review
by Joel FALCOU 23 Jan '15

23 Jan '15

The mini-review of Boost.Endian starts today and runs through Sunday, February 1. The library repository is available on GitHub at https://github.com/boostorg/endian The docs for the library can be viewed online at https://boostorg.github.io/endian/ The objective of the mini-review is to verify that the issues raised during the formal review have been addressed. Those issues are documented at https://boostorg.github.io/endian/mini_review_topics.html which also describes the resolution of each issue. Comments and suggestions unrelated to the mini-review issues are also welcome, but the key question the review manager needs your opinion on is this: Is the library ready to be added to Boost releases? -- Joel Falcou, Endian Review Manager

1 0