April 2017 - Boost - lists.preview.boost.org

[dynamic_bitset] Comparison operators without assertions
by Pavel Kretov 18 May '17

18 May '17

Hi all. Looking through boost::dynamic_bitset code, I found a interesting inconsistency between its operator== and operator<. Namely, the first works well with bitsets of different size, while the second triggers an assertion: boost::dynamic_bitset<> a(std::string("111")), b(std::string("1110")); a == b; // false a < b; // Assertion `a.size() == b.size()' failed. This means that we cannot reliably use dynamic bitset within ordered containers like std::set or std::map. Since the standard library has distinct concepts of equality and equivalence (see [1]), it's fine to have different comparison behaviors in dynamic_bitset. However, as far as I can judge, equivalence is a metaphysically broader concept than equality, we shouldn't restrict it to bitsets of the same size only. So, the questions: 1. May I remove that assertion? (It won't be a breaking change, after all). 2. How about doing the same thing to bitwise operators, too? Instead of throwing an assertion if sizes don't match, it may be worth to generalize the operators definitions. I can see several possible schemes, but not all of them are consistent enough. 3. Shouldn't BOOST_ASSERT be used instead of the one from assert.h? ――― Pavel K. [1]: http://en.cppreference.com/w/cpp/concept/EqualityComparable

8 25

[Boost.Test] access to boost::unit_test::framework::master_test_suite().{argc, argv} outside from BOOST_TEST
by Olaf Peter 08 May '17

08 May '17

Hello, my test program uses boost.test datasets. I've wrote a filesystem loader for the input and expected data. Now I run into the problem, that boost::unit_test::framework::master_test_suite().{argc, argv} is only setup inside the tests self. My loader isn't a test case ... I can check it by using a simple mock, like struct app_mock { app_mock(); int const argc; char** const argv; }; app_mock::app_mock() : argc(boost::unit_test::framework::master_test_suite().argc) , argv(boost::unit_test::framework::master_test_suite().argv) { } BOOST_AUTO_TEST_CASE( app_mocker ) { app_mock app; std::cout << "Count = " << app.argc << '\n'; for(int i = 0; i != app.argc; i++) std::cout << "Arg = " << app.argv[i] << '\n'; } $ my_test -- my_args Count = 2 path/to/exe my_args these works, but as mentioned: dataset_loader::dataset_loader(fs::path const& path) { app_mock app; std::cout << "ARGC = " << boost::unit_test::framework::master_test_suite().argc << '\n'; read_files(path); } is always zero. How can I read the argc/argv values? Thanks, Olaf

2 4

[1.64] [ublas] Broken/regession due to Boost.Serialization changes
by Peppard 05 May '17

05 May '17

Hi, since the 1.64 release including e.g. boost/numeric/ublas/matrix.hpp gives an error like "no member named 'make_array' in namespace 'boost::serialization'", according to the official(?) test overview (http://www.boost.org/development/tests/master/developer/numeric-ublas.html) on a lot of systems. There have been discussions on this mailing list in Nov/Dec 2016 probably at least related to this ([boost] [serialization][ublas][test] failures in serialization causing regressions) and in Feb 2017 ([boost] [serialization][uBlas] Serialization still breaking anything that uses uBlas?), also there are several pull requests on GitHub, e.g. https://github.com/boostorg/ublas/pull/46. (I assume you are aware of this already, but I wonder why there was a release with a regression like this, maybe due to a maintainer missing? How are cases like these handled?) Thanks! (Sorry if this is a double post but the list address seemed to change from @wowbagger.crest.iu.edu to @lists.boost.org so I tried again.)

3 2

GMane reflection of Boost mailing list messages
by Edward Diener 03 May '17

03 May '17

I am a user of GMane in regard to Boost mailing lists and it appears that GMane is no longer picking up Boost mailing list changes or allowing users to respond to mailing list posts through the corresponding GMane ng. Does anyone know how to rectify this situation ? I recall that Boost might have changed who was hosting the mailing lists and I am wondering if this is the reason that GMane no longer works with Boost mailing lists. The GMane website appears to be in transition, and all links for contacting anyone at GMane have been removed. I did try to contact Lars Magne Ingebrigtsen, who has been running GMane, but I do not know if this will produce any results.

4 9

Fwd: [clang] clang-cl expansion of macros
by degski 01 May '17

01 May '17

On 16 April 2016 at 17:58, Edward Diener <eldiener(a)tropicsoft.com> wrote: > What I strongly suspect will finally happen is that clang will not fix > these emulation problems because they are too tricky and numerous to do. > Instead they will probably declare that their emulation is good enough for > the majority of preprocessor constructs and that Boost PP, which pushes the > preprocessor to its limits, is not meant to work with their flawed VC++ > emulation. I hope I am wrong about that supposition, but having spent much > time in Boost PP and Boost VMD trying to workaround VC++ non-standard > preprocessor behavior I can envision that having to code "down" to that > behavior in numerous complicated instances will be too much time consuming > work for the clang developers who have chosen to work with VC++ > preprocessor emulation. > I've successfully built boost-1.64 with VC1410 (from the developer command prompt). Trying to use boost with a project using Clang 4.0.0 (both the LLVM and C2 backends) gives me the following PP error messages: 1>------ Rebuild All started: Project: test, Configuration: Debug x64 ------ 1> In file included from test.cpp:16: 1> In file included from z:\vc\x64\include\boost/filesystem.hpp:16: 1> In file included from z:\vc\x64\include\boost/filesystem/path.hpp:28: 1> In file included from z:\vc\x64\include\boost/iterat or/iterator_facade.hpp:12: 1> In file included from z:\vc\x64\include\boost/iterat or/interoperable.hpp:11: 1> In file included from z:\vc\x64\include\boost/mpl/or.hpp:43: 1> In file included from z:\vc\x64\include\boost/mpl/au x_/include_preprocessed.hpp:37: 1>z:\vc\x64\include\boost/mpl/aux_/preprocessed/plain/or.hpp(59,7): error : too many arguments provided to function-like macro invocation 1> 2 1> ^ 1> z:\vc\x64\include\boost/preprocessor/facilities/expand.hpp(26,10): note: macro 'BOOST_PP_EXPAND_I' defined here 1> # define BOOST_PP_EXPAND_I(x) x 1> ^ 1> In file included from test.cpp:16: 1> In file included from z:\vc\x64\include\boost/filesystem.hpp:16: 1> In file included from z:\vc\x64\include\boost/filesystem/path.hpp:28: 1> In file included from z:\vc\x64\include\boost/iterat or/iterator_facade.hpp:12: 1> In file included from z:\vc\x64\include\boost/iterat or/interoperable.hpp:11: 1> In file included from z:\vc\x64\include\boost/mpl/or.hpp:43: 1> In file included from z:\vc\x64\include\boost/mpl/au x_/include_preprocessed.hpp:37: 1>z:\vc\x64\include\boost/mpl/aux_/preprocessed/plain/or.hpp(58,1): error : expected a qualified name after 'typename' 1> BOOST_MPL_AUX_NA_SPEC2( 1> ^ 1> z:\vc\x64\include\boost/mpl/aux_/na_spec.hpp(166,44): note: expanded from macro 'BOOST_MPL_AUX_NA_SPEC2' 1> #define BOOST_MPL_AUX_NA_SPEC2(i, j, name) \ 1> ^ 1> z:\vc\x64\include\boost/mpl/aux_/na_spec.hpp(64,11): note: expanded from macro '\ 1> 1> BOOST_MPL_AUX_NA_SPEC_MAIN' 1> BOOST_MPL_PP_PARAMS(i, typename T) \ 1> ^ 1> z:\vc\x64\include\boost/mpl/aux_/preprocessor/params.hpp(58,11): note: expanded from macro 'BOOST_MPL_PP_PARAMS' 1> , BOOST_MPL_PP_AUX_PARAM_FUNC \ 1> ^ 1> In file included from test.cpp:16: 1> In file included from z:\vc\x64\include\boost/filesystem.hpp:16: 1> In file included from z:\vc\x64\include\boost/filesystem/path.hpp:28: 1> In file included from z:\vc\x64\include\boost/iterat or/iterator_facade.hpp:12: 1> In file included from z:\vc\x64\include\boost/iterat or/interoperable.hpp:11: 1> In file included from z:\vc\x64\include\boost/mpl/or.hpp:43: 1> In file included from z:\vc\x64\include\boost/mpl/au x_/include_preprocessed.hpp:37: 1>z:\vc\x64\include\boost/mpl/aux_/preprocessed/plain/or.hpp(58,1): error : expected ',' or '>' in template-parameter-list Up till now I was using a hacked boost-1.62. So in order to see what would happen, I also built boost-1.63. Apart from a small change in type_with_alignment.hpp (adding a ckeck for _MSC_VER not to exist if __clang__ does exist in line 87), boost-1.63 compiles without a problem (no specific (relevant to the emulation) command line parameters). Is there a macro I should define or is there something else I should set/do in order to use boost-1.64 with Clang 4.0.0 on windows? Any other suggestions? degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798

3 13

[review] Review of PolyCollection will start in a few days
by Ion Gaztañaga 30 Apr '17

30 Apr '17

Dear Boost community, The formal review of Joaquín M López Muñoz's PolyCollection library will start on Wednesday, May 3rd and ends on May 12th. This library implements fast containers of polymorphic objects. Typically, polymorphic objects cannot be stored directly in regular containers and need be accessed through an indirection pointer, which introduces performance problems related to CPU caching and branch prediction. Boost.PolyCollection implements a novel data structure that is able to contiguously store polymorphic objects without such indirection, thus providing a value-semantics user interface and better performance. Three polymorphic collections are provided: * boost::base_collection * boost::function_collection * boost::any_collection dealing respectively with classic base/derived or OOP polymorphism, function wrapping in the spirit of std::function and so-called duck typing as implemented by Boost.TypeErasure. If you are interested, you can start preparing your review with the following information: Repositories: Incubator: http://blincubator.com/bi_library/polycollection/?gform_post_id=1643 Github: https://github.com/joaquintides/poly_collection and the documentation here: http://rawgit.com/joaquintides/poly_collection/website/doc/html/index.html See you on Wednesday! Ion

1 0

[integer][math]Heads up on revised gcd/lcm code
by John Maddock 30 Apr '17

30 Apr '17

First some history.... Some time ago, the old gcd/lcm code was moved from Boost.Math to Boost.Integer as a means of reducing inter-library dependencies. Unfortunately a number of tasks were never completed: the docs weren't added to Boost.Integer, and the Boost.Math code never got updated to redirect to the moved headers. Fast forward a couple of years and when Jeremy Murphy contributed a new version of the gcd/lcm code as part of supporting polynomial gcd, and since I'd completely forgotten about the move, this got integrated into Boost.Math leaving us with two divergent versions. As part of sorting this mess out, I've now pushed to Boost.Integer a "best of both" version of this code, so far as I can tell, all dependent libraries are unaffected by the change, though I do need to do some more work on supporting obsolete compilers I no longer have access to. The main enhancements are: * New mixed binary/Euclid algorithm added, this seems to be the best performing algorithm in most cases, and is now the default for most integer types (performance is deeply dependent on the input though, so your mileage may vary). * In addition to integer and rational support, polynomial gcd is now supported via boost::math::polynomial. * There are new range based gcd-lcm algorithms for calculating the gcd/lcm of all the values in an iterator range, this is primarily for polynomial gcd support. * There are new variadic overloads of gcd/lcm for calculating gcd/lcm over more than 2 values. * The gcd/lcm functions are now constexpr in C++14 land, this means that the old compile time calculation traits classes are rendered obsolete for current compilers. * The gcd/lcm functions are now noexcept where appropriate. * Compiler intrinsics are now used speed up binary-gcd steps where possible, sadly this is incompatible with constexpr support since the intrinsics aren't yet constexpr :( Please do let me know if you find any snags, best, John. --- This email has been checked for viruses by AVG. http://www.avg.com

3 17

Boost MultiIndex slow mass insertion
by miticodonati＠libero.it 29 Apr '17

29 Apr '17

I have the following structure: typedef boost::multi_index_container< MyClass, boost::multi_index::indexed_by< boost::multi_index::hashed_unique<boost::multi_index::member<MyClass, int, &MyClass::label>>, boost::multi_index::ordered_non_unique<boost::multi_index::member<MyClass, double, &MyClass::dist>> > > MyClassSet; If i populate it in a loop: MyClassSet all: for (int y = 0; y < input.rows; ++y) { MyClass c; // .... all.insert(c); } the insertion time is quite slow. It probably need to continuously re-order the underlying implementation. Anyway i would expect that populating it with a single call it would be faster (e.g. sorting the whole set only at the end). Example: std::vector<MyClass> vec; // ... MyClassSet all(vec.begin(), vec.end()); BUT... the times are almost equal. My question is: is this intended behaviour? Is there a faster way to mass populate the container (e.g. not enforcing the invariants/orderings at each 'insert')?

3 2

[clang] clang-cl expansion of macros
by Edward Diener 29 Apr '17

29 Apr '17

You can get clang-cl ( clang-win ) to show its VC++ emulated expansion of macros somewhat by passing the c++ option '-fmacro-backtrace-limit=0' to the compiler. It is still blessedly difficult to see the what and the why of clang's error messages when expanding macro using clang-cl, but at least it gives you a better chance of understanding where clang's emulation of VC++ has gone wrong. I have posted bug 27380 to the llvm/clang bug tracker at https://llvm.org/bugs/show_bug.cgi?id=27380 showing the main failure in VC++ emulation which I see when testing Boost PP with clang-cl.

3 8

[quickbook] diagnosing a missing [endsect]?
by Peter Dimov 28 Apr '17

28 Apr '17

I just noticed a missing [endsect] in the middle of one of the .qbk files in the Core documentation. The main .qbk file contains [include addressof.qbk] [include checked_delete.qbk] [include demangle.qbk] [include enable_if.qbk] [include explicit_operator_bool.qbk] [include ignore_unused.qbk] [include is_same.qbk] [include lightweight_test.qbk] [include no_exceptions_support.qbk] [include noncopyable.qbk] [include null_deleter.qbk] [include ref.qbk] [include scoped_enum.qbk] [include swap.qbk] [include typeinfo.qbk] and in the middle of lightweight_test.qbk an [endsect] was missing. The end result of it was that the following includes went into the [section] opened in lightweight_test.qbk, as subsections. This wasn't noticeable from a cursory look so it went unnoticed for a while. Is it worth diagnosing this problem in some way? We probably can't disallow unbalanced sections in an [include], but this could be a warning? (If someone pays it any attention, of course.) Presumably, at the end of the file there'll be a [section] left open? This could be made an error so it'd be harder to miss.

4 23