May 2019 - Boost - lists.preview.boost.org

[variant2] Review Results
by Michael Caisse 11 May '19

11 May '19

First, I would like to apologize to Peter and the those who took time to review Boost.Variant2 for the slow turn-around of a result. Thank you Peter for producing and submitting such a high-quality library for review. The code has been a pleasure to read and review. Thank you to the reviewers! Your participation in the process is what makes Boost libraries high-quality. I personally appreciate the time and effort that each of you have put into this review. ------------- Result ------------- Boost.Variant2 will be ACCEPTED after the following changes are made. An additional review will not be required. - The library will implement the strong guarantee: - If all alternatives have nothrow move, single buffer - else, double buffer - Improved documentation: - Addition of a tutorial - Addition of design motivation - Peter has indicated that triviality propagation will come in a future version. The initial Boost release need not support triviality propagation. - Expected will not be included but may be submitted for review at another time. ---------------- Review Verdicts ---------------- The following people provided reviews. Reject ---------- Andrezj Krzemienski Antony Polukhin Jan Herrmann Accept ---------- Emil Dotchevski Gavin Lambert Phil Endecott Conditionally Accept -------- Bjorn Reese Andrey Semashev Damian Jarek Niall Douglas Andrezj and Antony’s rejections were based on not having a valueless-by-exception state. Neither saw the selected design space worth considering and each believed the trade-off was dangerous for users. The Conditional Acceptance reviews voiced the following: - Strong preference for the strong guarantee (and therefore no need to provide “surprising” behaviour for the state after an exception.) - Improved documentation containing both tutorial and motivation sections. - Triviality propagation of the variant types. - Accepted without expected being contained. -------------- Some Thoughts -------------- There was a good amount of healthy discussion on the Developer Mail List concerning Variant2. I want to thank all of the participants for engaging with civility and keeping to the technical merits despite the galvanized opinions concerning valueless-by-exception and the basic exception guarantee. Over the past couple weeks I have re-read all of the discussion threads 3 or 4 times. While some people didn’t find value in the exchanges, this level of engagement about design trade-offs is one of the attributes that sets Boost reviews apart. They are not merely reviews discussing the quality of implementation but also the intricacies of design choices within the constraints and consistency of the language. When reviewers articulate their opinions the entire community learns and grows. The trade-offs that Peter made seem dangerous to some yet the exact correct formulation for others. There are even standard library implementers that don’t agree with std::variant’s valueless-by-exception. A high-quality variant that provides the strong exception guarantee is a type that has been missing from the programmer toolbox. Variant2 provides this. I will make an additional announcement to the community when the conditions for acceptance have been met. Thank you all for making Boost better! michael -- Michael Caisse Ciere Consulting ciere.com

7 6

To modularize, or not to modularize. What is the plan?
by Rene Rivera 10 May '19

10 May '19

Bringing this up because of the recent discussion in the 1.70.1 thread. And of course because this is the week that a certain BSC meets. Hence I thought I would clarify what I've meant my a modular Boost all this time. A modular Boost, to me, means a Boost that first and foremost a collection of independently consumable C++ libraries. That would have the following aspects to it: * An end user or library author can obtain a single Boost library of their choice and use it in their project, assuming they also obtain the appropriate dependencies of that library. * BoostOrg would not produce a monolithic, combined, merged, etc distribution. * BoostOrg would produce collectively tested milestone modular distributions. Sounds lovely right? ...I'll leave the discussion of merits to responses herein ;-) What would it take to reach that modular goal? Why do I keep saying we've been working on this for ages and ages? Briefly here's what it would take to get there (not in any particular order): * Abandon the single header include tree. * Abandon the monolithic build infrastructure. * Ban relative use of inter-library dependencies. * Explicit declaration of inter-library dependencies. * Strict normalized library layout. * Remove, and ban, dependency cycles at the inter-library user consumable granularity. There's probably more items that I've forgotten above. But this should be enough to converse about. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

14 63

[boost-ci][azp] Configuration for Azure Pipelines
by Mateusz Loskot 09 May '19

09 May '19

Hi, FYI, James approved and merge my submission of Azure Pipelines to the repository with common CI configuration templates. Here is the PR: https://github.com/boostorg/boost-ci/pull/16 The AzP configuration follows common conventions from the existing templates for Travis CI and AppVeyor, and steals from Boost.Build's azure-pipelines.yml crafted by Rene with a few pinches of AzP experience from Boost.GIL. The boost-ci README.md provides more details. Although James maintains boost-ci, he is neither able to test the AzP configuration (I tested it quite extensively myself) nor maintain it. If you will give it a go and notice any problems, please open new issues for boost-ci and I will do my best to help. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Fingerprint=C081 EA1B 4AFB 7C19 38BA 9C88 928D 7C2A BB2A C1F2

1 0

Introducing me, Sagnik Dey
by Sagnik Dey 08 May '19

08 May '19

Hello! I am pleased to announce that I will be working on the Boost.Real project as part of GSoC'19. Looking forward to a productive summer, producing quality code and getting to know the developer community better. Thank You, Sagnik Dey

1 0

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