- Boost - lists.boost.org

[graph] Plans to upgrade algorithms with Boost.Parameter named arguments
by Cromwell Enage 03 May '19

03 May '19

Hello, everyone! With the most significant changes to Boost.Parameter now in both the 'master' and 'develop' branches, one of my next major goals is to prepare a pull request to incorporate Boost.Parameter named arguments into Boost.Graph algorithms that currently use bgl_named_params. My personal fork, <https://github.com/CromwellEnage/graph>, has a working version of such algorithms. However, I'd like your feedback on how to upgrade the corresponding documentation. I have a rough draft for documenting the Boost.Parameter-enabled A* algorithms here for your review: < https://github.com/CromwellEnage/graph/blob/develop/doc/astar_search.html>. Please suggest improvements or state if you are sufficiently satisfied with its current form to be able to use the A* algorithms with Boost.Parameter named arguments. I plan to use the same documentation style for the other affected algorithms. Regards, Cromwell D. Enage

1 0

[disjoint_sets] content moved into boostorg/graph
by James E. King III 02 May '19

02 May '19

The CMT was maintaining a standalone repository for one class, disjoint_sets, of which the only internal boost usage was in graph and graph_parallel (which depends on graph). disjoint_sets has been moved into boostorg/graph on develop. The superproject has a PR to remove it as a submodule, and the boostdep tools has a PR to remove it from an exclusion list. The path to the header has been preserved, so external usage will remain unaffected for those who download boost as a package, as disjoint_sets is header-only. If you experience any issues on develop relating to the header boost/pending/disjoint_sets.hpp, make sure you have the latest boostorg/graph, and you can manually remove libs/disjoint_sets from your sandbox, that should resolve it until the other PR in the superproject comes along. Even after that is merged, I'm not sure how the defunct disjoint_sets will be handled in sandboxes and may still need to be manually removed. There is no useful content in disjoint_sets at this point. I had experienced some complaints from b2 about being unable to link the header because it was coming from the old repository when I staged this change. Thanks, Jim

2 1

[variant] Heads-up!
by Antony Polukhin 02 May '19

02 May '19

Hi, I've merged a very cool optimization by Nikita Kniazev into the master branch. From now on boost::variant does pointer stealing for recursive variants. This significantly improves the performance of the variants move constructors. However if you use a variant variable after the std::move for anything except destruction and assignment then you're getting an UB. Beware! -- Best regards, Antony Polukhin

9 25

Re: [boost] [variant] tests failing on master
by Nikita Kniazev 30 Apr '19

30 Apr '19

> boost.variant tests are failing on master. Whatever the bug is, it is also causing my signals2 tests that use variant to fail. Config needs develop to master merge to resolve the issue.

1 0

[variant] tests failing on master
by Frank Mori Hess 30 Apr '19

30 Apr '19

boost.variant tests are failing on master. Whatever the bug is, it is also causing my signals2 tests that use variant to fail. -- Frank

1 0

Re: [boost] [variant] Heads-up!
by Nikita Kniazev 29 Apr '19

29 Apr '19

There seems to be misunderstanding of what the thread is about. The short sum-up of the changes: Nothing changed for users that does not use recursive variant. The changes were applied mainly for recursive_wrapper, and affect recursive variant indirectly. The PR was proposed as a solution for two major recursive variant problems: * Move-only types support * Poor move performance (because of this one Spirit has its own variant) Most of the users are not affected by recursive_wrapper move constructor change. To hit it you have to visit (either directly, or with applying comparison operators) a recursive moved-out variant. > have to agree with Steven. Never empty guarantee is a crucial difference between Boost.Variant and std::variant. std::variant has no recursive variant support. In the common field nothing changed. See the comment above. > If the one negative is adding UB to valid existing code at the next point release, doesn't that outweigh any number of positive outcomes? I do not think there even a single user that visits moved-out variants. There is an assertation for such usage though. > Why wouldn't this be an opt-in strategy - this property of moves has been established for years now. Because it solves the bigger problems and for much more users that it potentially breaks.

2 2

[MP11] Loosing const-qualification on type result with GCC 4.8 only
by Mateusz Loskot 28 Apr '19

28 Apr '19

Hi, (initially posted to https://lists.boost.org/boost-users/2019/04/89778.php) I prepared a lenghty MWE which reproduces my problem with type manipulation using MP11 that for some reason looses const-qualification on a ::type result Here it is at https://godbolt.org/z/eCsakP and copied below. I hope the XXXXXX comments make sense and important static assertions in the main() at the bottom explain what is the expected result. ``` #include <boost/mp11.hpp> #include <cstdint> #include <type_traits> namespace mp11 = boost::mp11; template <typename BitField, int FirstBit, int NumBits, bool IsMutable> struct bit_range_reference { /* long definition, irrelevant */ }; template <typename BitField, typename FirstBit, typename NumBits> struct bit_range_reference_type { using type = bit_range_reference < BitField, FirstBit::value, NumBits::value, true > const; // XXXXXX Why this const gets lost with GCC 4.8 XXXXXX }; template <typename BitField, typename RangeBitSizes> class bit_range_reference_list { template <typename FirstBit, typename NumBits> using reference_type = typename bit_range_reference_type < BitField, FirstBit, NumBits >::type; // XXXXXX Should carry the const, shouldn't? GCC >4.8 do. // If RangeBitSizes is mp11::mp_list_c<int,7,7,2> // then first_bit_list will be mp11::mp_list_c<int,0,7,14,16> using first_bit_list = mp11::mp_fold_q < RangeBitSizes, mp11::mp_list<std::integral_constant<int, 0>>, mp11::mp_bind < mp11::mp_push_back, mp11::_1, mp11::mp_bind < mp11::mp_plus, mp11::mp_bind<mp11::mp_back, mp11::_1>, mp11::_2 > > >; static_assert(mp11::mp_at_c<first_bit_list, 0>::value == 0, "first bit must be 0"); public: using type = mp11::mp_transform < reference_type, mp11::mp_pop_back<first_bit_list>, RangeBitSizes >; }; using reference3_list = typename bit_range_reference_list < std::uint8_t, mp11::mp_list_c<int, 3> >::type; int main() { using r1_t = mp11::mp_at_c<reference3_list, 0>; using r2_t = bit_range_reference<std::uint8_t, 0, 3, true>; using r2c_t= bit_range_reference<std::uint8_t, 0, 3, true> const; //#if defined(__GNUC__) && (__GNUC__ == 4) // GCC 4.8 compiles, later versions of GCC fail to compile static_assert(std::is_same<r1_t, r2_t>::value, "GCC says r1_t is const-qualified"); //#else // GCC 4.9, 5, 6, 7, 8 versions compile, GCC 4.8 fail to compile static_assert(std::is_same<r1_t, r2c_t>::value, "GCC says r1_t is NOT const-qualified"); //#endif } ``` To summary, I expect this to yield true: std::is_same < mp11::mp_at_c<reference3_list, 0> bit_range_reference<std::uint8_t, 0, 3, true> const > I got this confirmed by all GCC versions but GCC 4.8. (clang and MSVC also seem to agree with the GCC >= 4.9) Is mp11::mp_transform loosing const-qualification or have I made a mistake somewhere? I'm using Boost.MP11 from Boost 1.70 and from current develop branch Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 3

[endian] Request for comments
by Peter Dimov 28 Apr '19

28 Apr '19

There are two things that I suspect need to be fixed in Boost.Endian, but the changes are breaking. 1. endian_arithmetic<...> derives publicly from endian_buffer<...>. Intuitively, this inheritance relationship doesn't seem right, and it prevents endian_arithmetic from being a C++03 POD, due to having a base class. 2. the data() member function returns char const*. This type is strongly associated with null-terminated strings, and as such, using it for the underlying bytes of the endian object seems error-prone. I'd much prefer to return `unsigned char const*` from data() (although in C++17 `std::byte const*` might be even better.) I can't however estimate with any certainty whether the (mostly aesthetic) benefit of these changes would outweigh the users' annoyance from their code being broken for no strong reason. Comments?

4 3

CMake, modular Boost, and other stories
by Mike 27 Apr '19

27 Apr '19

Coming at this from a different angle: It might make sense to reserve find_package(Boost_foo) for libraries that directly support installation from cmake. Not sure if such a split is a good idea, but I wanted to put it up for consideration. Best Mike

3 3

PartIcpation in Boost
by Edward Diener 27 Apr '19

27 Apr '19

For personal reasons I will not be able to participate in Boost as I have in the past, which means I will no longer be able to be part of CMT. I will continue to maintain the libraries I created for Boost, tti and VMD, as well as maintaining the preprocessor library created by Paul Mensonides. This means that I will not have the time or the will to be involved with other libraries any more, except on the most general level of discussion. For what it is worth I think that Cromwell Enage should become the maintainer of the Parameter library. I have not, and still do not understand, why when talented C++ programmers are willing to contribute heavily to Boost they are not encouraged and supported more. But this is not my problem. For those who are interested, the experimental C++ standard preprocessor which had been added for VC++ in VS2017 via the '/experimental:preprocessor' switch is still supported in VS2019, although not documented anywhere in the official VS2019 docs. Ths VC++ experimental preprocessor is fully supported in Boost PP and Boost VMD. Unfortunately this preprocessor can not pass all the Boost PP tests, although it has gotten a little better in VS2019 from VS2017. I posted bug reports in Microsoft's bug reporting system regarding its bugs. I have not bothered to test it with the VMD tests, since if it can not pass all the PP tests it is not going to pass the VMD tests. Also while clang on Windows, whether targeting gcc or VC++, passes all the Boost PP tests it fails to pass the VMD tests with lots of errors, seemingly because it is running out of memory ( ? ). I have not bothered reporting this to clang, since my previous experience has shown me that they are clearly not that interested in their Windows implementation. Both gcc on both Linux and Windows, and clang on Linux, pass all the Boost PP and VMD tests. Of course you can try all this out for yourself if you are interested. Edward Diener

3 2