- Boost - lists.preview.boost.org

Re: [boost] [doc][signals] Broken links for Boost 1.70
by Glen Fernandes 08 May '19

08 May '19

On 2019-04-15 at 21:46:18 Mateusz Loskot wrote: > On https://www.boost.org/doc/libs/1_70_0/ links to these documentations are broken: > > https://www.boost.org/doc/libs/1_70_0/libs/signals/ > > Could anyone help to identify what is going wrong with those and how to fix it? Signals was removed as a Boost library starting with in 1.69.0 and I had put a notice in the 1.69 release notes about this (section "Discontinued Libraries"). I've removed the links for Signals (v1) on the Libraries page going forward. e.g. https://www.boost.org/doc/libs/develop/libs/libraries.htm e.g. https://www.boost.org/doc/libs/develop/ Additionally, I've added an entry in the "Libraries Retired from Boost" on that first libraries page for Signals (v1) alongside compose. Glen

2 1

[any] ABI break
by Antony Polukhin 07 May '19

07 May '19

Hi, I'm planning to apply an ABI breaking change to the Boost.Any https://github.com/boostorg/any/pull/11 That PR makes the binaries that use boost::any smaller. For example libboost_program_options.so looses 4KB in size. Boost libraries were not guaranteeing ABI stability, but boost::any is quite often used across library boundaries. Double checking that there's no objections.

1 1

Lets do 1.70.1 WHO IS WITH ME!!!
by Vinnie Falco 06 May '19

06 May '19

A crashing defect in Beast was discovered shortly after release: <https://github.com/boostorg/beast/issues/1599> It happens under high load when things happen at just the right time (or wrong time depending on how you look at it). It *will* eventually happen to any long-lived connection that sees enough traffic and timeouts. The fix is trivial: <https://github.com/vinniefalco/beast/commit/8620439f8e38db62713cff55a428bf8…> Thanks to the detailed report we were able to write a unit test which reproduces it reliably. Is this worth putting up a 1.70.1 for? The timeout feature is new in 1.70 and it is rather a shame that people might not be able to use it because of a defect. Regards

8 19

b2 --layout=versioned compiler tag in library filename
by Paul Harris 06 May '19

06 May '19

Hi guys, In the past, b2 would build libraries named like so: libboost_atomic-gcc48-mt-d-1_60.so (note -gcc48-) I tried compiling Boost 1.66.0 (from boost-git) with gcc 8.3.0, but the library it generates is named: libboost_atomic-gcc-mt-d-x64-1_66.so (note the -gcc-) No compiler version number in the tag... I (and CMake) was expecting it to be named: libboost_atomic-gcc83-mt-d-x64-1_66.so (note the -gcc83-) To build, I did: ./bootstrap.sh --with-libraries="atomic" ./b2 --layout=versioned I then downloaded the 1.70.0 tarball and compiled that, and this time the result was: tar xfv boost_1_70_0.tar.bz2 cd boost_1_70_0/ ./bootstrap.sh --with-libraries="atomic" ./b2 --layout=versioned ls -l stage/lib libboost_atomic-gcc8-mt-d-x64-1_70.so I don't see any documentation around the compiler version tag, what is the current policy? thanks, Paul

5 7

[thread] compiler error gcc 7.3 on cygwin
by James E. King III 06 May '19

06 May '19

Getting an internal compiler error with gcc 7.3 but only on cygwin 64-bit. Jim@pulsar /cygdrive/c/boost/libs/thread $ ../../b2 --abbreviate-paths toolset=gcc cxxstd=11 define=_POSIX_C_SOURCE=200112L define=__USE_ISOC99 threadapi=pthread address-model=64 variant=release -q ... gcc.compile.c++ ../../bin.v2/libs/thread/test/test_10963_c.test/gcc-7.3.0/rls/cxstd-11-iso/thrd-mlt/vsblt-hdn/test_10963_c.o In file included from ../../boost/thread/detail/invoker.hpp:30:0, from ../../boost/thread/future.hpp:31, from ../../libs/thread/test/test_10963.cpp:13: ../../boost/thread/detail/invoke.hpp: In function ‘decltype (*(forward<A0>)(boost::detail::invoke::a0).*boost::detail::invoke::f) boost::detail::invoke(Fp&&, A0&&) [with Fp = void (boost::executors::basic_thread_pool::*)(); A0 = boost::executors::basic_thread_pool*]’: ../../boost/thread/detail/invoke.hpp:102:43: internal compiler error: in gimplify_expr, at gimplify.c:12006 return (*boost::forward<A0>(a0)).*f; ^ Please submit a full bug report, with preprocessed source if appropriate. See <https://gcc.gnu.org/bugs/> for instructions. "g++" -std=c++11 -fvisibility-inlines-hidden -m64 -mthreads -O3 -finline-functions -Wno-inline -Wall -pedantic -fvisibility=hidden -Wextra -Wno-long-long -Wno-unused-parameter -Wunused-function -pedantic -DBOOST_ALL_NO_LIB=1 -DBOOST_THREAD_THROW_IF_PRECONDITION_NOT_SATISFIED -DNDEBUG -D_POSIX_C_SOURCE=200112L -D__USE_ISOC99 -I"../.." -c -o "../../bin.v2/libs/thread/test/test_10963_c.test/gcc-7.3.0/rls/cxstd-11-iso/thrd-mlt/vsblt-hdn/test_10963_c.o" "../../libs/thread/test/test_10963.cpp" ...failed gcc.compile.c++ ../../bin.v2/libs/thread/test/test_10963_c.test/gcc-7.3.0/rls/cxstd-11-iso/thrd-mlt/vsblt-hdn/test_10963_c.o... If I change the C++ language level to 03 the problem goes away. I also cannot reproduce it on linux with the same version of compiler (but it probably isn't the exact same compiler code). Should I go ahead and file that gcc bug? - Jim

2 1

[boost-ci] Extended list of branches allowed to build
by Mateusz Loskot 03 May '19

03 May '19

Hi, This is to inform maintainers and contributors about little proposal I made to the common CI infrastructure maintained by James https://github.com/boostorg/boost-ci/pull/11 The comments should explain rationale behind extending the common naming convention to enable CI builds for topic branches (w/o changing branch filters in .travis.yml etc.). The PR has now been merged. I'd like to encourage mainainers who use the boost-ci setup to pull the update into the libraries. It may also be helpful to put a note in CONTRIBUTING.md or README.md to let contributors know that if they wish to test their contributions on their own CI accounts prior submitting it as PR, they should name their topic branches with prefixes: feature/*, fix/* or pr/* I hope this simple change to boost-ci would be adopted by across Boost libraries and make some contributors' life esier. "What would be great for one off contributors like me is if all CI scripts would support testing of feature branches in forked repositories by default." - from #boost at cpplang.slack.com Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Fingerprint=C081 EA1B 4AFB 7C19 38BA 9C88 928D 7C2A BB2A C1F2

1 0

[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