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

Boost Library Incubator recommended by steering committee
by Beman Dawes 18 Jun '14

18 Jun '14

The Boost Library Incubator (www.blincubator.com) is a web site conceived, designed, and implemented to alleviate the log-jam of libraries waiting to be reviewed by Boost. It helps new library submitters through the process, encourages development of an initial user base, and accumulates feedback in the form of comments, test results and Boost style reviews. The Boost Steering Committee has voted to recommend using the Boost Library Incubator as a prelude to getting a library reviewed by Boost. The Steering Committee recommends libraries currently in the Boost review queue be added to the Incubator by their developers. The relationship between Boost and the Incubator is purely informal, but there as several things Boosters can do to help make the Incubator a success. Authors can submit their libraries and respond to feedback. Users can experiment with submitted libraries and provide feedback on their experience. WordPress/php developers can contribute enhancements to the Boost Library Incubator implementation. The steering committee extends its thanks to Robert Ramey for launching the Boost Library Incubator! --The Boost Steering Committee

5 7

[modularization] Missing libs/core file
by Vicente J. Botet Escriba 18 Jun '14

18 Jun '14

Hi, I don't reach to get the last changes in libs/core after un update of the whole boost repository and it modules cd modular-boost git checkout master git pull git submodule update viboes$ pwd /Users/viboes/github/modular-boost/libs/core viboes$ ls What I need to do to see this new repository? Vicente

9 17

[1.56][multi_index][Sandia-intel-11.1] help with SIGSEVs
by Joaquin M Lopez Munoz 18 Jun '14

18 Jun '14

[I have previously posted to boost-testing to no avail] Hi, Boost.MultiIndex is all green on master except for these two tests with Intel 11.1 on Darwin: http://tinyurl.com/keofovz http://tinyurl.com/muhtnn2 which build fine but exit with code 139 (seg fault) on execution. Could someone with access to this environment trace the error down to more useful information such as the offending line, valgrind backlog or something? Thank you in advance, Joaquín M López Munoz Telefónica

1 0

[interest] Is there interest in planar angle library ?
by Matus Chochlik 17 Jun '14

17 Jun '14

Hi, I would like to gauge interest in adding a very lightweight library implementing a class for handling planar angles and related operations to Boost. The library sources and several examples of usage can be found here: https://github.com/matus-chochlik/angle It does not conform to Boost conventions yet, nor is there any documentation, but the library is very simple to use: There is a template angles::angle<T> representing planar angles, using type T to store the angle value in radians. Conversions for 10 common angle units are included and new units can easily be added. The library also implements construction functions and user-defined literal operators allowing to specify angles in various units and also implements overloads of functions like sin, cos, etc. The only external header that this library includes is standard `cmath`. Here follow some examples of usage: using namespace angles; for(angle<double> a; a < 4_turns; a += 45_deg) { std::cout << a.to<unit::degree>() << std::endl; } for(angle<double> a=-quarters(2); a <= quarters(2); a += gradians(50)) { std::cout << a.to<unit::turn>() << std::endl; } for(angle<double> a; a < turns(1); a += degrees(15)) { std::cout << sin(a) << std::endl; } assert(turns(1) == quarters(4)); assert(degrees(90) == gradians(100)); assert(degrees(45) == quarters(0.5)); assert(degrees(2) == minutes(120)); assert(minutes(4) == seconds(240)); assert(degrees(1) == seconds(3600)); assert(turns(0.5) == gradians(200)); assert(pi(1) == quarters(2)); assert( 3_o_clock == 90_deg); assert( 6_o_clock == 200_gon); assert( 7_o_clock == 210_deg); assert( 9_o_clock == 300_gon); assert(11_o_clock == 1_turns - 30_deg); assert(12_o_clock == 2_pi); Please let me know if you are interested in the 'Boostification' of this library or if you have any ideas on how it could be improved. Best regards, Matus

3 2

[bcp] Option for inlining namespace boost
by Anton Bikineev 17 Jun '14

17 Jun '14

Hi all, I know it is possibly a very specific case, but is it possible for bcp to make namespace boost as inline? Thanks.

1 0

[accumulators] broken on msvc
by Jürgen Hunold 17 Jun '14

17 Jun '14

Hi! It seems that Boost.Accumulators is broken for all msvc builds with error messages like: boost/accumulators/framework/accumulators/reference_accumulator.hpp(72) : error C2061: syntax error : identifier 'BOOST_PP_CAT' boost/accumulators/framework/accumulators/reference_accumulator.hpp(72) : fatal error C1903: unable to recover from previous error(s); stopping compilation (from http://www.boost.org/development/tests/develop/developer/output/teeks99-02e…) The regression page http://www.boost.org/development/tests/develop/developer/accumulators.html shows _all_ msvc builders failing. My own code broke with an identical message sometime last week. Any ideas? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold(a)gmx.eu ! Germany

5 10

clang toolset on mingw passes -mthreads instead of -pthread
by Peter Dimov 16 Jun '14

16 Jun '14

Can someone who is familiar with Boost.Build please look at the Clang toolset and figure out how can it be persuaded to use the correct -pthread option instead of -mthreads under Windows/MinGW?

3 3

[Modularization] Variant -> Math and the Serialization issue
by Stephen Kelly 16 Jun '14

16 Jun '14

Hello, In regard to the other thread on the subject, I take the position that it should not be a problem for a module to depend on the serialization module. I also take the position that there should not be an explosion of 'serialization foo' modules. That is why I propose reducing the dependencies of serialization, so that depending on serialization is not a problem. That is why I suggested removing the dependency serialization -> spirit The improvement resulting from that is shown here: http://www.steveire.com/boost/deps-june-14/serialization.png http://www.steveire.com/boost/after-edge-removal-june-14/serialization.png So, now we need to remove the dependencies of the second graph. I draw your attention to the following dependencies: serialization ->variant variant -> math math -> [lots of stuff] If the variant -> math edge is removed, we get this: http://www.steveire.com/boost/june-15-serialization-no-variant-math.png http://www.steveire.com/boost/june-15-serialization-no-variant-math.dot which is already a significant improvement. There may be more low hanging fruit remaining. Variant depends on math for a single metafunction. boost::math::static_lcm Can something be changed to make Variant not depend on Math? Thanks, Steve.

5 5

[thread] Promote detail::invoke
by Agustín K-ballo Bergé 16 Jun '14

16 Jun '14

Boost.Thread has a great implementation of `invoke` in it's detail namespace. I would like to see this moved outside of Threads, so that other libraries can benefit from it (or course, only if Vicente thinks this is ok). This seems like an ideal candidate for the Detail submodule, as several other libraries have a need for this piece of functionality. The implementation relies on `BOOST_THREAD_[RV|FWD]_REF`, which could be replaced by `BOOST_[RV|FWD]_REF`. This would mean introducing a dependency on Boost.Move, but I'll leave those details to the people leading the modularization effort. Regards, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com

2 2

[range] concept checks break chained range adaptors
by Jürgen Hunold 15 Jun '14

15 Jun '14

Hi Neil, the fix for #9851 broke some of our code. We use chained range adaptors like std::vector<std::string> separated std::set<Foo> foos; boost::copy(separated | boost::adaptors::transformed(boost::bind(Foo::fromString, _1)) | boost::adaptors::filtered(boost::bind(&Foo::isValid, _1)), std::inserter(foos, foos.end())); which fails with error: constructor for 'boost::transform_iterator<boost::_bi::bind_t<Foo, Foo (*)(const std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > &), boost::_bi::list1<boost::arg<1> > >, std::__1::__wrap_iter<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > *>, boost::use_default, boost::use_default>' must explicitly initialize the member 'm_f' which does not have a default constructor transform_iterator() { } Full testcase and error message attached. This compiles and works with 1.55.0. git bisect shows that this fails to compile from 5f2560f - Ticket 9851 - adaptors should perform concept check assertions. for gcc and for clang starting with e43796c - allow clang to use Range Concepts despite reporting GCC 4.2. msvc-12.0 fails, too. gcc-4.8.2 and clang-3.5 (trunk) for the record. Any chance to get this fixed for 1.56.0 ? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold(a)gmx.eu ! Germany

3 4