June 2014 - Boost - lists.boost.org

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

New dependency report
by Peter Dimov 15 Jun '14

15 Jun '14

I've taken care of the mpl -> detail detail -> iterator utility -> iterator critical dependencies, which improved things a bit. The new report is at http://www.pdimov.com/tmp/report-6d1f271/module-overview.html http://www.pdimov.com/tmp/report-6d1f271/module-levels.html It includes reverse dependencies for each module and has been generated from the develop branch of the super-project.

13 115

[Modularization] Dependency diagrams
by Stephen Kelly 15 Jun '14

15 Jun '14

Hello, I have uploaded dependency diagrams for all boost libraries here: http://www.steveire.com/boost/deps-june-14/ The following incidental modules exist: incidentalModules["mpl"] = ("mpl", "type_traits", "typeof", "utility") incidentalModules["math"] = ("math", "lexical_cast") incidentalModules["spirit"] = ("spirit", "pool", "thread", "date_time", "serialization", "chrono", "interprocess") incidentalModules["graph"] = ("graph_", "disjoint_sets", "bimap", "property_map", "mpi", "graph_parallel") incidentalModules["scope_exit"] = ("scope_exit", "local_function") incidentalModules["range"] = ("range", "algorithm", "tr1", "random") The "incidental spirit" module and the "incidental range" modules are problematic. When the serialization->spirit range->algorithm edges are removed, they cease to exist as incidental modules, and the dependency graphs simplify: http://www.steveire.com/boost/after-edge-removal-june-14/ Compare: http://www.steveire.com/boost/deps-june-14/assign.png http://www.steveire.com/boost/after-edge-removal-june-14/assign.png http://www.steveire.com/boost/deps-june-14/range.png http://www.steveire.com/boost/after-edge-removal-june-14/range.png There are obviously more edges that can be investigated, but I recommend addressing serialization->spirit range->algorithm as a priority for now to remove those incidental modules. The "incidental mpl" module is not a priority problem, because anything which depends on the "incidental mpl" module mostly also depends on its dependencies. So, transitively speaking, it is mostly not a problem. It would be nice to resolve it a bit, but it does not need to be a priority. http://www.steveire.com/boost/deps-june-14/mpl.png The "incidental graph" module is not a priority problem because few other modules depend on any of it (only numeric_odeint). So, transitively speaking, it is mostly not a problem. It would still be nice to resolve it a bit to affect the modules inside the closure, but it does not need to be a priority. http://www.steveire.com/boost/graph-rdeps-june-14.png The "incidental scope_exit" module is being addressed afaiu, but it is also not a problem, transitively speaking. Nothing depends on either of them. Thanks, Steve.

2 1

[boost.test] Invoking test case from within another case
by Philip Bennefall 14 Jun '14

14 Jun '14

Hi all, I have built a performance measurement template function that can measure the time that a given piece of code takes to run, as well as provide some statistics such as standard deviation over x iterations etc. I am looking to integrate this into my existing boost.test setup, in a new suite called performance. This works fine if I write new test cases inside the performance test suite that invoke this function, but my goal is to also be able to run preexisting test cases in other suites to measure their performance. It'd be a bit hacky to have to include them again inside the new namespace. Is there a way to invoke a test in a specific test suite from inside another test case? Kind regards, Philip Bennefall

1 0

How do I download module Core?
by Andrzej Krzemienski 14 Jun '14

14 Jun '14

Hi, I can see that module Core is already available on branch Master. But when I try to pull the sources from GitHub (with 'git pull --rebase') it doesn't show up in my clone. Do I need to do anything to see it? Regards, &rzej

5 10

[modular] Re: [regression] Test results unavailable
by Rene Rivera 13 Jun '14

13 Jun '14

It's broken.. Don't know why though. Perhaps the recent code moves have made the testing tools not compile? On Fri, Jun 13, 2014 at 3:04 PM, Adam Wulkiewicz <adam.wulkiewicz(a)gmail.com> wrote: > Hi, > > I noticed that the results are unavailable. Was this planned or is > something broken? > > Regards, > Adam > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

4 5

[regression] Test results unavailable
by Adam Wulkiewicz 13 Jun '14

13 Jun '14

Hi, I noticed that the results are unavailable. Was this planned or is something broken? Regards, Adam

1 0