June 2014 - Boost - lists.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