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

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

19 Jun '14

On Tue, Jun 17, 2014 at 11:52 PM, Robert Ramey <ramey(a)rrsd.com> wrote: > how would this differ from boost units? > For one thing, in its dependencies, Boost.Units is a wonderful library, but for many use-cases it is too heavyweight. As mentioned before this library depends only on standard cmath. Also this library is more specialized on angle operations than Boost.Units is, at least out of the box. Matus

2 2

[gil] Optimizations
by Harg Tholan 19 Jun '14

19 Jun '14

Hi all, I've been wondering whether is there any room for ASM optimizations in GIL. Regards, H4rg.

2 1

[modularization] spirtit -> serialization
by Vicente J. Botet Escriba 19 Jun '14

19 Jun '14

Hi, comments about this dependency: |<boost/serialization/vector.hpp>| * from |<boost/spirit/home/support/detail/lexer/serialise.hpp>| It seems that this file is not used |boost/spirit/home/support/detail/lexer/serialise.hpp Could this file be removed or moves to examples? Best, Vicente |

10 58

Interest in bit-wise flags?
by Jeffrey Bush 19 Jun '14

19 Jun '14

Hi Boost! I have developed a type-safe bit-wise flags class for my own personal use and am wondering if it would be of interest for me to submit it as a Boost library. At the moment it is not ready for submission (code is messy) but I am testing the waters so I present an overview below. * Fully ISO standard C++11 (except for an MSVC version which is API-compatible except it doesn't support as many an infinite number of flag names) * They are type-safe, requiring explicit casts to and from integers/booleans * Supports standard bit-wise operations, and always keep values within the possible set of flags * Supports getting the name of a flag and looking up flags by name at run-time (when a flag is actually multiple-flags it gives something like "A|B") * Supports getting an array of all flags at run-time Now the bad things, which may be a deal-breaker: * Because of limitations in C++ the syntax can feel a bit awkward. You have to use a macro to define flag-names (which actually creates a class) then you can pass those flag-names as template arguments to the flags. An example: FLAG_NAME(A); FLAG_NAME(B); FLAG_NAME(C); typedef Flags<std::uint8_t, Flag_A, Flag_B, Flag_C>::WithValues<0x01, 0x02, 0x04> MyFlags; * I also couldn't get around using the ::WithValues nested class * I use a set of macros to make this cleaner (e.g. the above could be FLAGS(A, B, C)) and once defined there is no more ugliness Thanks for consideration! Jeff

5 5

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

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

[random] new threefry random engine
by Thijs van den Berg 13 Jun '14

13 Jun '14

Hi all, I've completed a nice new random engine that I would like to propose for addition to boost/random. The engine is called "threefry" and it's based on the paper "Parallel random numbers: as easy as 1, 2, 3" by Salmon, John K. and Moraes, Mark A. and Dror, Ron O. and Shaw, David E. I've been using it myself a lot for the last couple of years, and now I've rewritten it so that it will fit in the boost random framework and adhere to the concepts. It has some really nice properties, in particular for large scale parallel computing: * High quality randomness (according to the BigCrush tests) with a cycle length of 2^258 * Fast (comparable to Mersenne Twister) & little memory usage (13x 64 bit integers) * O(1) discard and guarantees for non-overlapping sequences when the (up to 256 bit) seeds are unequal I've uploaded the code, description and tests to https://github.com/sitmo/threefry The actual engine is at https://github.com/sitmo/threefry/blob/master/random/include/boost/random/t… I would really appreciate any feedback about the idea for inclusion and of course comments about the quality of the code,tests,docs kind regards, Thijs Sitmo Consultancy B.V. Financial Modelling & Data Science + 31 6 24110061 thijs(a)sitmo.com P.O. Box 1059, 2600BB, Delft, The Netherlands

10 60

Errors Compiling in AIX 7.1 with gcc
by Axel Ismirlian 13 Jun '14

13 Jun '14

Hello, I am trying to compile boost on AIX 7.1 with gcc, but I am getting several errors. The configuration checks report that zlib support is disabled even though I do have that package installed. I also don't have icu support. Is there a package for that in AIX? I was not able to find one. Performing configuration checks - symlinks supported : yes - 32-bit : yes - arm : no - mips1 : no - power : yes - lockfree boost::atomic_flag : yes - has_icu builds : no warning: Graph library does not contain MPI-based parallel components. note: to enable them, add "using mpi ;" to your user-config.jam - zlib : no - iconv (libc) : no - iconv (separate) : yes - icu : no - icu (lib64) : no - x86 : no - gcc visibility : no - long double support : yes warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. - zlib : no I also tried adding a user-config.jam in the boost/ (the same place as the project-config.jam) in order to add some flags to my gcc compilation and to use mpi, but my jam was soundly ignored. However, the most concerning of these errors is some apparent assembler error. gcc.compile.asm bin.v2/libs/context/build/gcc-4.8.1/release/link-static/threading-multi/asm/make_ ppc32_sysv_xcoff_gas.o Assembler: /tmp//cc0uhEhf.s: line 5: 1252-016 The specified opcode or pseudo-op is not valid. Use supported instructions or pseudo-ops only. /tmp//cc0uhEhf.s: line 8: 1252-016 The specified opcode or pseudo-op is not valid. Use supported instructions or pseudo-ops only. /tmp//cc0uhEhf.s: line 8: 1252-016 The specified opcode or pseudo-op is not valid. Use supported instructions or pseudo-ops only. /tmp//cc0uhEhf.s: line 8: 1252-016 The specified opcode or pseudo-op is not valid. Use supported instructions or pseudo-ops only. /tmp//cc0uhEhf.s: line 8: 1252-016 The specified opcode or pseudo-op is not valid. Use supported instructions or pseudo-ops only. /tmp//cc0uhEhf.s: line 11: 1252-142 Syntax error. /tmp//cc0uhEhf.s: line 15: 1252-142 Syntax error. /tmp//cc0uhEhf.s: line 19: 1252-142 Syntax error. /tmp//cc0uhEhf.s: line 22: 1252-142 Syntax error. /tmp//cc0uhEhf.s: line 25: 1252-142 Syntax error. /tmp//cc0uhEhf.s: line 27: 1252-142 Syntax error. /tmp//cc0uhEhf.s: line 28: 1252-142 Syntax error. /tmp//cc0uhEhf.s: line 30: 1252-142 Syntax error. /tmp//cc0uhEhf.s: line 32: 1252-142 Syntax error. /tmp//cc0uhEhf.s: line 34: 1252-142 Syntax error. /tmp//cc0uhEhf.s: line 37: 1252-142 Syntax error. /tmp//cc0uhEhf.s: line 40: 1252-142 Syntax error. /tmp//cc0uhEhf.s: line 46: 1252-142 Syntax error. /tmp//cc0uhEhf.s: line 48: 1252-142 Syntax error. /tmp//cc0uhEhf.s: line 50: 1252-142 Syntax error. /tmp//cc0uhEhf.s: line 53: 1252-142 Syntax error. I'm not sure how to go about fixing that. When I go to my /tmp/ directory ccvhH2Fc.s is not an assembler file present. Right after this message another error appears. ...failed gcc.compile.asm bin.v2/libs/context/build/gcc-4.8.1/release/link-static/threading-multi /asm/jump_ppc32_sysv_xcoff_gas.o... gcc.compile.c++ bin.v2/libs/context/build/gcc-4.8.1/release/link-static/threading-multi/untested. o libs/context/src/untested.cpp:7:2: error: #error "! code for this platform is untested - please r emove this file from build/Jamfile.v2 and report the test-result on boost-track !" #error "! code for this platform is untested - please remove this file from build/Jamfile.v2 and report the test-result on boost-track !" What is the complete path for the Jamfile.v2 that this error refers to? Any advice the community can offer would be greatly appreciated. Sincerely, -Axel

2 1

[thread] Mass test failures on clang
by Andrey Semashev 13 Jun '14

13 Jun '14

Hi, I'm seeing mass test failures in Atomic and Log both in develop and master. E.g.: http://www.boost.org/development/tests/develop/developer/atomic.html http://www.boost.org/development/tests/master/developer/atomic.html The logs are not descriptive (as usual) but point to Thread compilation: http://www.boost.org/development/tests/develop/developer/output/teeks99-04b… Could this be resolved? The freeze deadline is nearing, so I'd like to see my test results at least once before it is reached.

4 12

Code review for bug no. 7396
by ullas srinivas 13 Jun '14

13 Jun '14

Hi, I have fixed bug no. 7396 Bug # 7396 :filesystem::path::remove_all(path, error_code) throws filesystem_error exception Description : Several methods in filesystem::path, including remove_all, have an overload in which an extra error_code& argument is taken. According to the docs, this is supposed to cause failure (other than failure to allocate storage) to be reported in the error_code rather than as a thrown filesystem_error exception. However, remove_all can still throw filesystem_error exceptions because it uses a directory_iterator internally but makes no attempt to catch exceptions thrown by it. For example, if a subdirectory is deleted by another thread or process just before remove_all tries to list its contents, directory_iterator_construct will throw a filesystem_error that propagates up to remove_all's caller. As a side note, I think path and directory_iterator are both excessively exception-happy. It makes them painful to use. Root Cause : The exceptions thrown by fs::directory_iterator were not handled in remove_all_aux function of operations.cpp file. Fix: The exceptions thrown by fs::directory_iterator are handled by catching the exception and proper ly assigning error values . Try-catch statement has been put inside remove_all_aux function of operations.cpp file. I kindly request you to please find the patch file attached and review the bug Regards Ullas

1 0

[test] Compilation errors on MinGW 4.8.1
by Adam Wulkiewicz 12 Jun '14

12 Jun '14

Hi, When I try to compile Boost.Test (develop) tests or any other tests using execution_monitor on MinGW-GCC 4.8.1 I get the following errors: ..\..\../boost/test/execution_monitor.hpp:364:27: error: 'FE_DIVBYZERO' was not declared in this scope BOOST_FPE_DIVBYZERO = FE_DIVBYZERO, ^ ..\..\../boost/test/execution_monitor.hpp:365:27: error: 'FE_INEXACT' was not declared in this scope BOOST_FPE_INEXACT = FE_INEXACT, ^ ..\..\../boost/test/execution_monitor.hpp:366:27: error: 'FE_INVALID' was not declared in this scope BOOST_FPE_INVALID = FE_INVALID, ^ ..\..\../boost/test/execution_monitor.hpp:367:27: error: 'FE_OVERFLOW' was not declared in this scope BOOST_FPE_OVERFLOW = FE_OVERFLOW, ^ ..\..\../boost/test/execution_monitor.hpp:368:27: error: 'FE_UNDERFLOW' was not declared in this scope BOOST_FPE_UNDERFLOW = FE_UNDERFLOW, ^ ..\..\../boost/test/execution_monitor.hpp:370:27: error: 'FE_ALL_EXCEPT' was not declared in this scope BOOST_FPE_ALL = FE_ALL_EXCEPT, ^ When I use MinGW-GCC 4.8.0 shipped with Qt5 everything is ok. I though I'll let you know since AFAIS this toolset isn't tested. If you decided to take a look at this and needed a guinea pig I'd be here. Regards, Adam

3 6

Building Boost on Haiku
by Andrew Hudson 12 Jun '14

12 Jun '14

Hi, New booster here. I am building Boost 1.55 on Haiku X86 and have a build issue: -pthreads is not recognized by GCC 4.8 on Haiku X86 and gives an error. pthreads are supported by Haiku by default, so I need to suppress the compiler option but enable pthreads in the build. I used ./bootstrap.sh -PREFIX to set the default lib path as /usr is not used in Haiku Then I started the build with ./b2 install Where and how can I make this config change? I have little jam experience. I also need to suppress use of MPI as this is not ported yet. Many thanks!

1 0

Meeting C++ Schedule released
by Jens Weller 12 Jun '14

12 Jun '14

Hello C++ & Boost Community, since last week the schedule for Meeting C++ is released: http://meetingcpp.com/index.php/schedule14.html Like last year Meeting C++ will feature 21 Talks in 3 Tracks, the conference will be opened by Scott Meyers, the closing Keynote will be given by Hartmut Kaiser. This years Theme Track is "Scientific Programming with C++". Also, if your are a student, you have the chance to participate in our student program which will give 50 Students access to the conference: http://meetingcpp.com/index.php/newsreader/items/meeting-cpp-2014-the-stude… kind regards, Jens Weller

1 0

[config] config_test fails on g++ 4.8/4.9
by Peter Dimov 12 Jun '14

12 Jun '14

... due to In file included from ../libs/config/test/config_test.cpp:376:0: ../libs/config/test/boost_no_lambdas.ipp: In function ???int boost_no_cxx11_lambdas::test()???: ../libs/config/test/boost_no_lambdas.ipp:21:4: error: expected primary-expression before ???void??? (void)[](){}; ^ ../libs/config/test/boost_no_lambdas.ipp:21:4: error: expected ???)??? before ???void??? I'm not sure why.

3 5

[review] Convert library
by Jeroen Habraken 12 Jun '14

12 Jun '14

Hi, As promised my review of the boost::convert library. Note that the questions were answered in a seemingly random order, thus I hope it all comes together. Secondly, being the author of the boost::coerce library [2][3] I may be a little biased at times, please forgive me. -- What is your evaluation of the design? There are two parts to this, the design of the backend and the design of the interface that the user predominantly sees. I have little to say on the first, the notion of multiple backend converters is a big step forwards and their interface is sane. I'm far less convinced when it comes to the user-facing interface as I believe the simple tasks should be simple and intuitive, whereas the harder tasks may be harder. The most trivial use of boost::convert, and boost::lexical_cast and boost::coerce simply don't compare in my opinion. boost::cstringstream_converter cnv; int i = boost::convert<int>::from("23", cnv).value(); versus int i = boost::lexical_cast<int>("23"); int j = boost::coerce::as<int>("23"); When the convert library makes it into boost I'd want to mentally deprecate lexical_cast as a library I should use, and always use convert instead. This means convert should have a default converter, which may well be backed by lexical_cast with an interface such as: int i = boost::convert<int>::from("23").value(); This still doesn't completely satisfy me as I'd like to write int i = boost::convert<int>::from("23"); but it'd be an improvement in my opinion. Now I'm aware lexical_cast doesn't have a non-throwing interface, and it probably never will, but I've solved the problem as follows in boost::coerce: int i = boost::coerce::as_default<int>("XXX"); int j = boost::coerce::as_default<int>("XXX", tag::hex()); int k = boost::coerce::as_default<int>("XXX", 23); int l = boost::coerce::as_default<int>("XXX", tag::hex(), 23); The former two returning the default-constructed int, 0, the latter two returning 23. That said, I'll be the first to admit the coerce interface isn't perfect, the fact that I need SFINAE to distinguish between as_default calls with two parameters, the second either being a tag (somewhat similar to your converters but not quite) or the default value goes to show just that. However I'd prefer int i = boost::convert<int>::from("23", cnv); int i = boost::convert<int>::from_default("23", cnv, 0); to the current interface using value_or(0). This is subjective though, and quite possibly a matter of taste. In summary, before this turns into too long a rant, I think the current user-facing interface can be improved substantially, but I'm well aware this is subjective. -- What is your evaluation of the implementation? I've only had a quick glance at the code and it still looks fine. The gripe I had two years ago regarding the use of reserved names (include guards prefixed with "__") has been fixed. A few comments though: In the boost::lexical_cast based converter there is a try { } catch (...) { } which I believe to be an overly broad catch as lexical_cast explicitly throws a boost::bad_lexical_cast. If in an unlikely event a std::bad_alloc were to be thrown for example I'd rather not have boost::convert hide it from me. In the std::strtol based converter errno isn't checked, and it must be noted that strtol accepts leading whitespace which may or may not be wanted. I've implemented what I believe to be a correct converter using strtol which checks for the leading whitespace in [0], but it comes with no guarantees as it's quite tricky indeed. The new C++11 wrapper std::stol and friends in [1] may be of use here, but unfortunately they only have a throwing interface. All converters are added to the main boost namespace which is crowded enough as it is -- hi boost::_1 --, and libraries should add their functionality to their own namespaces in my opinion. With the current design it's not possible to add them in the boost::convert namespace but I believe they should be in their own namespace, may I suggest boost::converter. It must be said that the first two comments are minor at best, the last regarding the namespace is more important but potentially quite trivial to fix. -- What is your evaluation of the documentation? I've found it to be very hard to write documentation as the library author as at some point you're so intimately familiar with your library that it's hard to get a feel for what the user needs. Whilst there are some rough edges I think the current documentation is decent enough for it not to pose a problem. Again a few comments: The motivation should probably be addressed first, not near the end. The printf and std::strtol based converters aren't documented, and the converters should probably be grouped into a sub-section along with an explanation of how to write your own. Last of all I'd like to see an examples directory showing the examples from the documentation, you already have a test/encryption.hpp which probably belongs there. -- What is your evaluation of the potential usefulness of the library? In the previous review I've argued the library its functionality should be added to boost::lexical_cast. Whilst I still hold that position for the previous version of the library I believe this is no longer the case for the present version, largely due to the added support for multiple backends. There would be no practical way for lexical_cast to add this, and I believe it to be very useful indeed. -- Did you try to use the library? With what compiler? Did you have any problems? I've tried the library with Clang 3.2 and 3.4, and GCC 4.6 and 4.8 on Mac OS X 10.9.3 and the examples from the documentation using the sstream converter compile and run fine. When I tried the printf_converter something as simple as: #include <boost/convert/api.hpp> #include <boost/convert/converter/printf.hpp> int main(int, char *[]) { return boost::convert<int>::from("23", boost::printf_converter()).value(); } failed to compile. It's missing includes as adding the following to converter/printf.hpp fixes the problem: #include <boost/mpl/find.hpp> #include <boost/mpl/vector.hpp> This probably indicates that you're trying to test too much in a single file, and had the includes included via a different boost library. In the previous review I noticed that boost::convert<int>::from('1', cnv).value() spew a rather long error message. This has since been fixed, the error message is now considerably shorter making it easier -- will it ever be easy with C++ -- to figure out what's going on. I must note here that the error message the latest versions of GCC produced is actually easier to figure out than the one Clang produced. -- How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Something between a quick reading and an in-depth study, now probably leaning towards the latter. -- Are you knowledgeable about the problem domain? As the author of boost::coerce, which I've admittedly ignored for far too long, I'm familiar with the conversion domain. Consequently I've seen the pitfalls and endured the hardships in designing and implementing such a library, my utmost respect for having it reviewed not once, but twice! And finally: -- Do you think the library should be accepted as a Boost library? In my previous review this was a straight no, stating that the functionality should be added to boost::lexical_cast. With the current design supporting multiple backends this no longer holds true as I've stated in the evaluation of the potential usefulness of the library. Again, the library is quite useful, but, I so strongly disagree with the current user-facing interface that I can't straight-out accept it. Once the library is accepted this interface is set in stone and like marriage it's "speak now or forever hold your peace". As such I'm voting YES, CONDITIONALLY on the interface being simplified for the seemingly simple cases as most of my other comments were minor or quite trivial to fix. With that out of the way I'd like to propose the following if you're interested. Let's have a look at whether it may be possible to merge the functionally of boost::convert and boost::coerce, as they seem to have grown towards each other with the possibility to support multiple backends. Two years ago I'd never have proposed this, but I've mellowed a bit since then. You seem to have focussed on backends primarily backed by std::stringstream and friends whereas I have focussed on a backend backed by boost::spirit. These may end up complementing leading to a single library capable of supporting both, being more generic and powerful to the user when done right. Regardless of whether we end up going this way I'd love to have a discussion on the interface, either on the mailing list or offline as this is currently a major stumbling block for me. Jeroen [0] https://github.com/VeXocide/coerce/blob/master/libs/coerce/example/backend.… [1] http://en.cppreference.com/w/cpp/string/basic_string/stol [2] https://github.com/VeXocide/coerce/ [3] http://vexocide.org/coerce/

15 78

Even newer dependency report
by Peter Dimov 12 Jun '14

12 Jun '14

Shows significant progress. http://www.pdimov.com/tmp/report-d6c23cf/module-overview.html http://www.pdimov.com/tmp/report-d6c23cf/module-levels.html

2 3

a new library Global Object Manager submission interest check
by George Georgiev 11 Jun '14

11 Jun '14

Hi, I have code that deals with problems related to initialization of global objects (singletons). 1. Multi-threading - problems occurring in some singleton patterns based on the fact that local for a function or method static variables are not initialized in a thread safe manner 2. Initialization order - there is no multi-platform/multi-compiler standard way to control the global objects initialization order 3. Static linking of global objects code without need - some patterns result in global objects to be linked in the final executable, even if they are provided from static libraries and the code that uses them is not in use 4. Capability for easy replacement of a global implementation object with a mock object I was struggling with shutdown issues in complex c++ application for years in several different projects. With the solution I come up a few years ago I have no issues in any project I have used it. Please let me know if this is something of interest to the boost community. Note that the boost singleton pattern used for path_locale (boost filesystem path) is having the multi-thread issue I mentioned in point 1. This is a small test that demonstrates the problem: https://github.com/ggeorgiev/boost-filesystem-singletons/blob/master/filesy… Thanks, George

3 10

[range] why not adding conversion operator std::pair<FTI.FTI> to boost iterator_range
by Andreas Fabri 11 Jun '14

11 Jun '14

Wouldn't it be a good idea to add a conversion operator to the class iterator_range? This would allow to write functions returning a range, instead of a pair of iterators, but boost::tie would still work with it. Best regards, andreas -- Andreas Fabri, PhD Chief Officer, GeometryFactory Editor, The CGAL Project phone: +33.492.954.912 skype: andreas.fabri

3 4

[BGL]
by Pablo Madoery 11 Jun '14

11 Jun '14

Hello, I Have 2 graphs: graph1 and graph2, and two sets of edge descriptors. One set is associated to edges of graph1 and another set associated to edges of graph2. I don't understand why is it possible to access information about edges of graph2 by using graph1 and the edge descriptors of graph2. I realized of that because of an own mistake when using graphs. What I would like to know is why is that possible to do and if it should be an exception that can handle this situation. I send the code I was using to test this: #include <iostream> #include <boost/graph/adjacency_list.hpp> #include <boost/graph/graphviz.hpp> #include <fstream> #include "GraphInfo.h" using namespace std; using namespace boost; typedef adjacency_list<setS, vecS, bidirectionalS, VertexInfo, EdgeInfo> Graph; void printGraph(Graph graph, string file) { ofstream ofs(file.c_str()); dynamic_properties dp; dp.property("node_id", get(vertex_index, graph)); dp.property("label", get(&EdgeInfo::weight, graph)); write_graphviz_dp(ofs, graph, dp); } int main() { Graph graph1; Graph::vertex_descriptor a1 = add_vertex(graph1); Graph::vertex_descriptor b1 = add_vertex(graph1); Graph::vertex_descriptor c1 = add_vertex(graph1); Graph::edge_descriptor e1 = (add_edge(a1, b1, graph1)).first; Graph::edge_descriptor e2 = (add_edge(b1, a1, graph1)).first; graph1[a1].id = 10; graph1[b1].id = 20; graph1[c1].id = 30; graph1[e1].weight = 1; graph1[e2].weight = 2; Graph graph2; Graph::vertex_descriptor a2 = add_vertex(graph2); Graph::vertex_descriptor b2 = add_vertex(graph2); Graph::vertex_descriptor c2 = add_vertex(graph2); Graph::vertex_descriptor d2 = add_vertex(graph2); Graph::edge_descriptor e4 = (add_edge(c2, b2, graph2)).first; Graph::edge_descriptor e5 = (add_edge(b2, c2, graph2)).first; Graph::edge_descriptor e6 = (add_edge(d2, a2, graph2)).first; Graph::edge_descriptor e7 = (add_edge(a2, d2, graph2)).first; graph2[a2].id = 10; graph2[b2].id = 20; graph2[c2].id = 30; graph2[e4].weight = 13; graph2[e5].weight = 14; graph2[e6].weight = 15; graph2[e7].weight = 16; // WHY IS THIS POSSIBLE TO DO // IT IS ASKING FOR AN EDGE OF GRAPH2 BUT USING GRAPH1 ??? double weight = graph1[e7].weight; cout<<"weight: "<<weight<<endl; printGraph(graph1, "graph1.dot"); printGraph(graph2, "graph2.dot"); cout << "end" << endl; return 0; } Thank you very much

1 0

[pimpl] No documentation for pointer semantics
by Edward Diener 10 Jun '14

10 Jun '14

The documentation for "Pimpl with Value Semantics" has: "and was deployed in the previous chapter for the Pimpls with pointer semantics..." but there is no previous chapter about Pimpl with pointer semantics. From that point on the documentation of "Pimpl with Value Semantics makes no sense to me and I do not know what is being explained.

8 24

[Modularization] new Memory module
by Vicente J. Botet Escriba 10 Jun '14

10 Jun '14

|What about creating a Memory module containing| most of the things the standard defines in <memory> except maybe what is already in SmartPptr, e.g. ||* boost/interprocess/allocators/*|| |* boost/intrusive/pointer_traits.hpp Vicente |

5 22

Tick: Trait instrospection library for C++14
by paul Fultz 10 Jun '14

10 Jun '14

Hi, I developed a trait introspection library for C++14 based on Eric Niebler's concept checking, here: https://github.com/pfultz2/Tick So you can build a simple `is_incrementable` trait like this: TICK_TRAIT(is_incrementable) { template<class T> auto requires(T&& x) -> TICK_VALID( x++, ++x ); }; Then use it like this: static_assert(is_incrementable<T>(), "Not incrementable"); Also, you can validate the return of an expressions like this: TICK_TRAIT(is_equality_comparable) { template<class T, class U> auto requires(T&& x, U&& y) -> TICK_VALID( returns<bool>(x == y), returns<bool>(x != y) ); }; You can also match against another trait using placeholder expressions: TICK_TRAIT(is_incrementable) { template<class T> auto requires(T&& x) -> TICK_VALID( return<std::is_integral<_>>(x++), return<std::is_integral<_>>(++x) ); }; Any feedback would be appreciated. Also, I don't knw if there would be any interest in incorporating this into boost. Thanks, Paul

7 13

[config] RTTI detection on Intel C++
by Peter Dimov 10 Jun '14

10 Jun '14

I was going to prepare a simple pull request that basically added #if !defined(__RTTI) && !defined(__INTEL_RTTI__) && !defined(__GXX_RTTI) && !defined(_CPPRTTI) #define BOOST_NO_RTTI #define BOOST_NO_TYPEID #endif to intel.hpp, but then I saw that this file doesn't contain any logic for BOOST_NO_EXCEPTIONS, relying instead on common_edg.hpp to check __EXCEPTIONS. So I wonder whether the preferred approach wouldn't be to check __RTTI in common_edg.hpp instead. Opinions? There's also a slight complication here because I suspect that when Intel is in Microsoft mode, when RTTI is off it will still support typeid, as MSVC does; so just BOOST_NO_RTTI would need to be defined, and not BOOST_NO_TYPEID.

2 2

quickbook equivalent of <simplesect>?
by Peter Dimov 10 Jun '14

10 Jun '14

Does Quickbook support <simplesect> or an equivalent? This is useful for the 'Authors' sections in Core, which don't need to clutter the ToC.

2 9

documentation (ToC) question
by Peter Dimov 10 Jun '14

10 Jun '14

When using Quickbook/BoostBook, how can a section ToC have two levels instead of just one? That is, if we have [library Boost.Core] [section:addressof addressof] [section Header 1] [section Synopsis] [section Example] [section Header 2] [section Synopsis] [section Example] how can the ToC of [section:addressof] show the Synopsis and Example nested within Header 1 and Header 2? I have tried various combinations of generate.section.toc.level, toc.max.depth, toc.section.depth, but nothing seems to produce the result I want.

4 7

[modularization] Recommendations
by Stephen Kelly 10 Jun '14

10 Jun '14

Hello, My last set of recommendations is here: http://thread.gmane.org/gmane.comp.lib.boost.devel/245078/focus=245806 The current graph of strongly connected modules is: http://www.steveire.com/boost/2014_june8_all.dot http://www.steveire.com/boost/2014_june8_all.png The type_traits mpl typeof core form a closed cylce. I consider this a small problem and I recommend deferring efforts to resolve it for now and focusing on the other edges which impact the rest of the graph. It may not be realistic to resolve every cycle or doing so may involve merging modules etc. I recommend deferring that discussion/work until after the major cycle-forming-edges are resolved. Group the above in the graph as a single node for now, removing many cycles: http://www.steveire.com/boost/2014_june8_with_kernel.png http://www.steveire.com/boost/2014_june8_with_kernel.dot Recommendation 1) Move parenthesized_type.hpp from parameter to core This removes the dependency from concept_check on parameter. Recommendation 2) Move implicit_cast.hpp and cast.hpp from conversion to core This also requires moving select_type.hpp from detail to core. This allows removal of the dependencies from iterator and range to conversion. As a side effect, it leaves lexical_cast as the only remaining public header in the conversion library. You can decide what impact that has for the recent 'Extracting lexical_cast from conversion' discussion. This requires removing the include of numeric/conversion/cast.hpp from cast.hpp. The content of that was moved to the numeric library in 2005 and the include was left behind for source compatibility. The result of the above recommendations is: http://www.steveire.com/boost/2014_june8_conversion_rdep.png http://www.steveire.com/boost/2014_june8_conversion_rdep.dot Recommendation 3) Remove use of algorithm from range Range includes boost/algorithm/string/config.hpp for no known purpose. According to git log -S BOOST_STRING_TYPENAME that define was never used in the range library. According to the history of boost/algorithm/string/config.hpp it never really had anything else useful. It might have made sense to include it for the Borland portability with the BOOST_STRING_TYPENAME, but that define was never used in range. Simply remove the use of the boost/algorithm/string/config.hpp header. Use boost/type_traits/detail/yes_no_type.hpp instead of boost/algorithm/string/yes_no_type.hpp in include/boost/range/detail/collection_traits_detail.hpp The resulting strongly connected graph is http://www.steveire.com/boost/2014_june8_range_deps.png http://www.steveire.com/boost/2014_june8_range_deps.dot There are more recommendations which can be made to reduce the strongly connected graph further, but I think the above are enough for now, so let's see if we can get through those first. Thanks, Steve.

6 19

[testing] Dissapearing regression results
by Adam Wulkiewicz 10 Jun '14

10 Jun '14

Hi, I noticed that for the latest runs the tests of Geometry are missing. Surprisingly not all, 2 tests for geometry/index sublib are present. Initially I thought that it may be caused by the recent modularization but I didn't noticed any problems in any of the libraries I checked randomly. Besides, I made some changes in Geometry recently, which AFAIU shouldn't cause any problems, but I guess you may never know. What I changed was: - creation of some files - moving of some files - adding a Jamfile in a directory different than test directories (doc/src/docutils/tools/support_status) - uncommenting tests in file extensions/test/nsphere/Jamfile.v2 So I decided to try running the tests by myself. I tried: 1. Windows + GitBash -> a lot of "can't find xxx file" errors (b2 headers didn't work properly) 2. Windows + GitBash with admin rights -> exactly what can be seen in the tests, bjam.log shows that only 2 tests from Geometry was choosen for testing 3. Windows + cmd with admin rights -> everything is ok (in case you wanted to check it - runner Test2) 4. Linux -> also everything is ok (runner Test) Is it possible that I was lucky and something was fixed yesterday evening (between 2nd and 3rd attempt)? Might my changes cause some problems? E.g. because of some state kept by the runners? In Geometry we have Jamfiles not only in test and xxx/test directories but also in examples, docs and in the main module directory. May this cause some problems? At least for me, on Windows b2 headers now requires admin rights. Otherwise the links just aren't created. Is it because of the replacing hardlinks with symlinks? Another thing is that symlinks aren't properly created for all libraries. AFAIR previously something like this happened after the addition of sublibs file. I don't remember exactly but it was probably caused by the same names of the older tests and newer ones from different directories, so not the same issue? Is there something we could do about it? Regards, Adam

3 9

- Request to join the community maintenance team
by Neil Groves 10 Jun '14

10 Jun '14

Hi! Please may I would like to join all the cool kids in the community maintenance team?! I would like to assist on various maintenance issues and with the modularisation effort. I think this requires broader write access than I have at the moment as a maintainer of Boost.Range. It seems to me that joining the community maintenance team will both allow me to help more with general maintenance and assist with modularisation. If the correct procedure is to make different requests, then please let me know. Regards, Neil Groves

2 1

[pimpl] Boost.Pimpl review canceled
by Glen Fernandes 09 Jun '14

09 Jun '14

Hi everyone, Vladimir has elected to withdraw Boost.Pimpl submission and cancel the formal review. On behalf of Vladimir, thank you for the feedback provided in response to the pre-view announcement mail: it was especially useful to him. Best, Glen

1 0

[Modularization] About adding sub-modules?
by Vicente J. Botet Escriba 09 Jun '14

09 Jun '14

Hi, some libraries can be seen as a set of sub-modules, as it is Math, Numeric or Thread. Could we add these sub-modules ? * Chrono/Stopwatches * Thread/Executors * Detail/WinApi Best, Vicente

4 13

Re: [boost] [Modularization] new Memory module
by Vicente J. Botet Escriba 09 Jun '14

09 Jun '14

I forget to sent this message to the boost ML. Le 09/06/14 15:18, Vicente J. Botet Escriba a écrit : > Le 09/06/14 12:17, Ion Gaztañaga a écrit : >> El 09/06/2014 10:11, Vicente J. Botet Escriba escribió: >>> Le 04/06/14 13:27, Vicente J. Botet Escriba a écrit : >>>> |What about creating a Memory module containing| most of the things >>>> the standard defines in <memory> except maybe what is already in >>>> SmartPptr, e.g. >>>> >>>> ||* boost/interprocess/allocators/*|| >>>> |* boost/intrusive/pointer_traits.hpp >>>> | >>> Any comments on this new module? Ion? >> >> Thanks for the ping, I'm not closely following modularization threads. >> >> Interprocess allocators are only usable by Interprocess users, I >> don't think they should be outside. > > Sorry, I wanted to say container| > > <boost/container/allocator_traits.hpp>|| > <boost/container/scoped_allocator.hpp>||| > > >> intrusive::pointer_traits is usable from other libraries. Container >> uses it extensively, but Container heavily depends on Intrusive. I >> don't know if other libraries use it. > > Boost.Thread uses allocators for future<T>. >> >> We also have a portable allocator_traits implementation in >> Boost.Container that might be reusable by other boost containers. We >> need to see real use cases to see if this class makes sense in >> Boost.Memory or its place should be Container. > I'm for Memory as it is in the standard. See my use case for future<T> >> >> For Boost 1.56 we'll have new allocators in Boost.Container, and >> those take advantage of Boost.Container internals to offer >> reallocation, burst allocation, etc. They could be usable by other >> Boost containers, but they are still experimental and unless there is >> a strong need for that, I would not move them to a new module now. >> >> pointer_traits offers extensions not found in std::pointer_traits >> (like pointer casting). We need to to carefully think about this >> (Boost.Intrusive needs to make some conversions not covered by >> std::pointer_traits). >> >> In any case, if reusable, I would make a new library (with >> documentation and test cases), not only a new git module. >> > Agreed. >> So my opinion is: Don't move interprocess allocators, let's see if a >> strong need arises for a common pointer_traits/allocator_traits and >> we'll think about solutions. >> > We don't move nothing we can not do either because we are the owners > or because these are libraries managed by the community maintenance team. > > Please, take the time you need about this new module/library that > could contain things similar to the ones found in <memory> except the > smart pointer part. > > Best, > Vicente

2 1

[ublas] Mass test failures on msvc12 and other on all msvc versions
by Adam Wulkiewicz 09 Jun '14

09 Jun '14

Hi, Nearly all tests fails for msvc12 because of the use of constexpr keyword. Could this be fixed? I prepared a pull request nearly a month ago: https://github.com/boostorg/ublas/pull/5 Btw, in those tests failing for all MSVC versions an assertion failure is reported by the STL: map/set iterators incompatible. Assertion failures should be visible in the regression results, shouldn't they? At least in the file test_inplace_solve.cpp (of course with -DUSE_MAPPED_VECTOR_OF_MAPPED_VECTOR) this assertion failure is caused by the matrix_sparse.hpp line 2002: return it_ == it.it_; Which is called by: triangular.hpp line 1328 matrix_expression.hpp line 1598 iterator.hpp line 185 ... test_inplace_solve.cpp line 72 I hope that helps. Do you plan to release the version of uBlas from develop in 1.56? Regards, Adam

4 4

[modularization] proposal and poll
by Julian Gonggrijp 09 Jun '14

09 Jun '14

Dear Boost mailing list members, I would like to revive the topic of Boost inter-library dependencies, suggest two global changes to Boost and ask whether you agree with the course of action I propose. RATIONALE Boost recently transitioned from a monolithic SVN repository to a "modular" Git repository. One of the potential benefits of this new structure is that it may allow users to copy much less of Boost when they need only a small part of it. I believe that two additional, evolutionary changes are needed to truly unlock that benefit. The currently-standard way to use the new Git repository is to recursively clone the super-project and all its submodules, one for each of the >100 libraries. In order to use Boost in a truly modular way, a developer would rather just clone only the libraries she needs (including dependencies). Unfortunately, there is currently no feasible way to do that [see also 1]: - Manually: this is cumbersome and generally hard because there are many (undocumented) interdependencies between Boost libraries. - Automatically: as far as I know Ryppl is the only existing attempt at providing automated dependency handling for Boost, but it is a very ambitious project that attempts to do much more and it is currently neither finished nor being actively developed. I think there could be a less ambitious but faster way to provide automated dependency handling. It would take no more than some static configuration, to list for each library what other Boost libraries it depends on, combined with a simple script that automatically traverses the dependency graph and clones just the necessary submodules. This script may then be hooked into the bootstrap script. I think I could write the dependency handler, and I would be willing to, though I can't currently provide any indication of when I would be able to start. However, even if we had an automated way to handle dependencies, that would not be a sufficient solution to true modularity. As has been discussed before, the interdependencies between Boost libraries are currently so strong, that even using a single header file may likely require the user to copy a substantial portion of Boost [2]. This is especially the case because there are many cyclical dependencies [3, 4]. Stephen Kelly investigated how the interdependencies between Boost libraries could be reduced, especially the cyclical dependencies. He concluded that most cyclical dependencies could be eliminated and that the dependency graph could be simplified substantially overall. He also described concrete ways to achieve this. [3 and onwards] I believe it would still be worthwhile to reduce interdependencies between Boost libraries in the way Stephen proposed, or with a very similar approach. Stephen told me he is willing to re-analyze the dependencies as many times as needed as he did before and to make recommendations. Together with an automated way to handle dependencies, this should enable users to install only a small portion of Boost if that is all they need. It will also make the Boost super- project more flexible overall. PROPOSAL The following (evolutionary) global changes to Boost should be planned and given priority over any other proposals [e.g. 5], in the following order: 1. Reduction of dependencies between Boost libraries. 2. Simple but effective automation of dependency handling. POLL I think it may be easier for the steering committee to justify any decision on this proposal, if they have hard statistics about the amount of support it receives. Therefore, I invite every opinionated person reading this to reply with a vote, either in favour of the proposal or against it. I invite you to do this even if you do not feel the need or find the time to provide arguments for your position. You can later re-vote if you change your mind. I will count the votes, and when there are more than 30 I will start posting the statistics occasionally. Votes are public so everyone can verify my data when necessary. Anyone, including the steering committee, can then use the numbers however they choose. Thanks in advance, -Julian ____________ [1] http://lists.boost.org/Archives/boost/2014/05/213115.php [2] http://lists.boost.org/Archives/boost/2013/10/207379.php [3] http://lists.boost.org/Archives/boost/2013/10/207384.php [4] http://lists.boost.org/Archives/boost/2013/10/207422.php [5] http://lists.boost.org/Archives/boost/2014/05/213229.php

15 49

[1.56.0] Heads up: One week to cutoff for new libraries and breaking changes
by Beman Dawes 09 Jun '14

09 Jun '14

As a practical matter, I'd also like to see the dependency reduction effort wind down for a while so more eyes can shift to finding and fixing master regression test errors. Thanks, --Beman

2 1

detail/interlocked.hpp -> winapi?
by Peter Dimov 09 Jun '14

09 Jun '14

The window for having fun with moving files around is closing quickly, so if detail/interlocked.hpp is going to be moved to winapi, now is the time. It makes atomic depend on detail, which doesn't really matter at the moment, but could become relevant at some later date. C:\Projects\boost-git\boost>%boostdep% boost/detail/interlocked.hpp Inclusion report for <boost/detail/interlocked.hpp> (in module detail): from atomic: <boost/atomic/detail/interlocked.hpp> from interprocess: <boost/interprocess/detail/win32_api.hpp> from log: <boost/log/detail/spin_mutex.hpp> from thread: <boost/thread/win32/basic_timed_mutex.hpp> <boost/thread/win32/interlocked_read.hpp> <boost/thread/win32/once.hpp> <boost/thread/win32/shared_mutex.hpp> <boost/thread/win32/thread_primitives.hpp>

3 9

[type_traits] Proposal: same_xxx
by Adam Wulkiewicz 09 Jun '14

09 Jun '14

Hi, Recently I found some use for a tool adding const to a type if some other type is const. My use case was something like this: typename const_conformant < Range, typename boost::range_value<Range>::type >::type ... I'm guessing that such use cases are quite common, not only for const but also other qualifiers. Do you think that a family of traits adding or removing qualifiers based on the qualifiers of some other type could be a useful addon to the TypeTraits? E.g.: same_const<BaseT, T> same_cv<BaseT, T> same_pointer<BaseT, T> same_reference<BaseT, T> same_rvalue_reference<BaseT, T> same_volatile<BaseT, T> same_extents<BaseT, T> //etc. Regards, Adam

4 5