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

Re: [boost] proposal a movable_initializer_list
by 何子杰Hzj_jie 19 Sep '14

19 Sep '14

No body interests in it? I trust if the initializer_list is movable, it would be great helpful to construct a class with a set of lambda expressions. And we can use these lambda expressions to define a procedure, and provide a better solution for asynchronous programming. .Hzj_jie ________________________________ From: 何子杰Hzj_jie<mailto:hzj_jie@hotmail.com> Sent: ‎16/‎9/‎2014 10:35 To: boost(a)lists.boost.org<mailto:boost@lists.boost.org> Subject: Re: [boost] proposal a movable_initializer_list sorry, my fault of the mistake of for-range usage, you are correct, I am using iterator in my implementation. The efficiency I am taking care is the difference between copy-construction and move-construction. It will be significant if we are using lambda expression. Surely we still have something else to improve, say, provide the size of the vector at construction. The way using movable_initializer_list in the test case is not typical, indeed I am trying another not related issue. <the order of the move-constructions are not expected, i.e. line 46 will throw errors by g++, but no problem by msvc> Usually if a class A accept movable_initializer_list<T> as the parameter of a constructor, we only need A({T(), T()}), i.e. same as initializer_list. You properly would like to have a look at the event class, which is the typical scenario of movable_initializer_list, at https://github.com/Hzj-jie/osi/blob/master/delegates/event.hpp, with a test at https://github.com/Hzj-jie/osi/blob/master/utt_cases/delegates/event_test.h…. briefly it uses movable_initializer_list to avoid a copy of std::function instances, but can provide a way to call constructor with { } syntax. .Hzj_jie From: Sebastian Redl Sent: ‎Monday‎, ‎September‎ ‎15‎, ‎2014 ‎8‎:‎09‎ ‎PM To: boost(a)lists.boost.org On 15 Sep 2014, at 9:39, 何子杰Hzj_jie <hzj_jie(a)hotmail.com> wrote: > hi, all, > > So I proposal a movable_initializer_list, it accepts two ways to construct, with an initializer_list<T*> or initializer_list<T>, the prototype is, > > The implementation of T* overloads is something like > > movable_initializer_list<std::initializer_list<T*> x) > > { > > for(auto it : x) > > { > > assert((*it) != nullptr); > > v.push_back(std::move(**it)); > > delete *it; > > } > } Should be for (auto p : x) { v.push_back(std::move(*p)); delete p; } because of how for-range works. Seems an incomplete manual change from your published source. However, this is highly problematic because: - There is absolutely no way to make this exception-safe. The intended usage is obviously: SomeType st = { new Foo(123), new Foo(456), new Foo(789) }; But if any constructor here throws, a lot of memory is leaked, and destructors are not called. - If efficiency is your goal, I somehow doubt that an additional dynamic allocation per element for the initial list, then building a vector element by element, is the best way to achieve it. - The interface to this is just horrible. Looking at your test case, there is an absurd amount of boilerplate. Here’s what we really want: SomeType st{ Foo(123), Foo(456), Foo(789) }; Here’s what your thing forces me to do: auto pointers = { new Foo(123), new Foo(456), new Foo(789) }; SomeType st(pointers); // Absolute best case: no ambiguity in overload resolution - actually rather doubtful. If you do it that way, you might as well do it this way: Foo[] foos = [ Foo(123), Foo(456), Foo(789) }; // No dynamic allocation SomeType st(make_move_iterator(begin(foos)), make_move_iterator(end(foos))); More efficient, and you could make helpers that combine the make_move_iterator and begin/end calls to reduce boilerplate. > > While the implementation of T overloads is something like > > moveable_initializer_list<std::initializer_list<T> x) > { > > for(auto it : x) v.push_back(move(*it)); > } Again, that’s not how for-range works. What you want is for (auto&& e : x) v.push_back(std::move(e)); But that doesn’t actually work, because a std::initializer_list never gives you non-const access to its elements. I notice that your test case doesn’t test this constructor. Sebastian _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Boost incubator milestone
by Robert Ramey 19 Sep '14

19 Sep '14

The boost library incubator (www.blincubator.com) has received it's first Boost quality review for one of its submitted libraries. See the review here: http://rrsd.com/blincubator.com/reviews/?library_post_id=669 Hopefully this will motivate more people to submit their own reviews in advance of some formal review period. BTW - this review of this library (Compute) is very positive. Hopefully this will motivate other potential users to try out the library and make their own review. If the number of reviews reaches 5 I'll ask that the formal review for this library be expedited since, given such a head start, the review should be much simpler than starting from scratch. So I'm encouraging people who want to get the review process on a faster track to submit their own reviews as soon as they can find time. The Incubator has been progressing more slowly than I would hope. But progress is being made. Hopefully, this will continue to the point where it becomes and "overnight" success. Thanks to Denis Demidov for breaking the ice here. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-incubator-milestone-tp4667761.html Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

Re: [boost] TravisCI and Coverall usage policies in Boost
by Marek Kurdej 19 Sep '14

19 Sep '14

Hi, > If we ever get Windows on Travis, I was surprised how good the MSVC > static analyser has become, and we should have a pass with that too. > FYI, there is a CI similar to Travis running MSVC-12.0, see https://ci.appveyor.com/. I've used it for a personal project, you can have a look at a sample configuration file using Boost libraries at https://github.com/mkurdej/bft/blob/develop/appveyor.yml. The only problem, there is only a 30-day free trial... Cheers, Marek Kurdej -- Ph.D. candidate

1 0

Trac spam report
by Joaquín M Lopez Munoz 19 Sep '14

19 Sep '14

https://svn.boost.org/trac/boost/ticket/10502 Thank you Joaquín M López Muñoz Telefónica

2 1

[regression] Debian-sid
by Suckow, Thomas J 18 Sep '14

18 Sep '14

Someone has been running regression tests on develop with the name “Debian-sid”, I believe they have a space in the path to the regression suite, which is causing it to fail. The job gets run like clockwork, shame that it isn’t uploading any useful results. Either the operator of this builder should change the path so that it does not have a space, or the regression suite should be updated to tolerate it. I tried once to figure out where in the test suite the path got mangled, but was unsuccessful, maybe someone more familiar with it could take a look? - Thomas

2 3

[type_traits] Modularization proposal
by Andrey Semashev 17 Sep '14

17 Sep '14

Hi, Boost.TypeTraits is used in lots of other Boost libraries, and it currently unnecessarily pulls MPL and TypeOf. The dependencies are introduced by just these two public headers: floating_point_promotion.hpp and common_type.hpp. I'd like to avoid these dependencies. I propose to extract common_type.hpp (and its implementation and tests) into a sublib within type_traits (e.g. type_traits/common_type). As for floating_point_promotion.hpp, it is used in promote.hpp, which is using integral_promotion.hpp. I can see two ways of tackling it: 1. Extract all promotion traits into a sublib (e.g. type_traits/promotion). This includes floating_point_promotion.hpp, integral_promotion.hpp and promote.hpp, as well as their tests. 2. Change floating_point_promotion.hpp to not use MPL. MPL is used only to workaround BOOST_NO_CV_SPECIALIZATIONS, which is defined for Borland 5.51 and older and MPW 8.90 and older. The simplest way is to drop the workaround, but at a quick glance it should be possible to retain it. I'm currently leaning towards the option 2, although we obviously don't test those compilers and there is no way of knowing if the code will still work after the change. So I'm interested to know others' opinion, both with regard to the general idea and the way of proceeding with floating_point_promotion.hpp in particular. PS: TypeTraits dependencies can be seen in the report Peter graciously uploaded: http://www.pdimov.com/tmp/report-d5ca5be/type_traits.html After the modularization efforts TypeTraits should only depend on Config, Core, Preprocessor, MPL.Core and StaticAssert. Don't mind that MPL.Core depends on MPL - the pull request fixing it has already been created.

8 23

[mpl] Modularization pull request
by Andrey Semashev 17 Sep '14

17 Sep '14

Hi, I've created this pull request: https://github.com/boostorg/mpl/pull/11 to separate core components of Boost.MPL to a sub-library. The intent of this pull request is to reduce dependencies added by MPL to its dependent libraries, when only the basic MPL components are required. In particular, it should help resolving circular dependency between MPL and TypeTraits. Please, have a look at the list of moved components and let me know if you have any comments.

4 18

[testing] mpl/core tests not visible
by Andrey Semashev 17 Sep '14

17 Sep '14

Hi, I can see a few testers have cycled since MPL.Core was extracted into a sublibrary, but there is no mpl/core page in the test matrix. The sublibs file and core/test directory are present in the mpl submodule. Is there something I should do to make the tests appear?

3 21

[TR1] Reming TR1? [was: Libraries failing across the board.]
by Beman Dawes 16 Sep '14

16 Sep '14

On Wed, Jul 9, 2014 at 8:13 AM, John Maddock <boost.regex(a)virgin.net> wrote: > > > On 08/07/2014 22:07, Beman Dawes wrote: > >> Marshall is just a few days away from being able to put out a beta release >> candidate. (And that is very good news!) >> >> But we still have too many libraries failing across the board on master: >> >> accumulators >> interprocess >> numeric/ublas >> pool >> proto >> spirit/repository >> spirit/test >> tr1 >> > > TR1 is now deprecated, and again hasn't been changed in a long time - the > main failures seem to be caused by changes to Boost.Random (or possibly > std::random) so that it is now no longer TR1 compliant. Someone would have > to rewrite it to use TR1-compatible random number classes perhaps culled > from an old version of Boost, frankly I just don't see the point. The lib > should probably be removed from Boost at some point. > We went back and forth a bit, and decided to remove TR1 after 1.56.0 shipped. What exactly needs to be done? * Remove the .gitmodules entry. * Remove the status/Jamfile.v2 entry. * Remove the libs/maintainer.txt entry. * Update http://www.boost.org/doc/libs/ Anything else? --Beman

5 4

[modularization] mplcore depends on mpl
by Stephen Kelly 16 Sep '14

16 Sep '14

Hi there, libs/mpl/core/include/boost/mpl/aux_/include_preprocessed.hpp from mplcore includes boost/mpl/aux_/config/compiler.hpp which is in mpl. mpl depends on mplcore. This is a circular dependency. I thought the point of the split was to resolve that in part. If so, then I recommend you go ahead and resolve the cycle in the obvious way. Thanks, Steve.

2 1