- Boost - lists.boost.org

[rational] release (optimized) builds are failing unit tests
by James E. King, III 12 Jun '18

12 Jun '18

I am adding CI to Boost.Rational and the unit tests are failing for different levels of optimization on different compilers. Before I dig into it further, does anybody have any idea what this might be? https://github.com/boostorg/rational/issues/18 See issue for error output. Ubuntu Bionic gcc unit test succeeds: -O0, -O1 unit test fails: -O2, -O3 boost@17b66a9efac4:/boost/libs/rational/test$ g++ --version g++ (Ubuntu 7.3.0-16ubuntu3) 7.3.0clang unit test succeeds: -O0 unit test fails: -O1, -O2, -O3 boost@17b66a9efac4:/boost/libs/rational/test$ clang++-6.0 --version clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final) Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/bin To reproduce, try: boost@17b66a9efac4:/boost/libs/rational/test$ ../../../b2 toolset=clang variant=release rational_test I am using the ubuntu bionic docker container to do the build in. See boostorg/boost#184 <https://github.com/boostorg/boost/pull/184>

1 0

[release] 1.68.0 deadline for new libraries approaching
by Marshall Clow 12 Jun '18

12 Jun '18

One week from tomorrow master will closed for new libraries. Upcoming dates: * 20-Jun: Boost 1.68.0 closed for new libraries and breaking changes * 27-Jun: Boost 1.68.0 closed for major code changes * 4-Jul: Boost 1.68.0 closed for beta * 11-Jul: Boost 1.68.0 beta 1 * 1-Aug: Boost 1.68.0 closed for release * 4-Aug: Boost 1.68.0 release -- The Boost Release Team

1 0

meta/libraries.json question
by Antony Polukhin 11 Jun '18

11 Jun '18

Hello, I see that I can specify "std": [ "proposal" ], in meta/libraries.json. What are the other options? Can I write "с++17" instead of "proposal" (for Any and Variant)? -- Best regards, Antony Polukhin

1 0

boost::winapi and Windows CE 7 and Windows Mobile 6
by Vyacheslav Lanovets 07 Jun '18

07 Jun '18

Hello, I am having big trouble migrating from 1.65.1 to 1.67 in VS2008 for CE platform. We already have quite a few patches for boost we reapply on every update. Boost 1.67 added more issues here and there, and among them the winapi library. On our old CE 7.00 I have winnt.h file where the second branch get selected. #if (defined(_M_MRX000) || defined(_M_IX86) || defined(_M_ALPHA) || defined(_M_PPC) || defined(_M_IA64)) && !defined(MIDL_PASS) #define DECLSPEC_IMPORT __declspec(dllimport) #else #define DECLSPEC_IMPORT #endif Therefore, WINAPI functions are not imported but is linked via corelib.lib library. So when I compile my code I see 3>D:\Dev\boost167\boost/winapi/semaphore.hpp(48) : error C2375: 'CreateSemaphoreW' : redefinition; different linkage 3> C:\Program Files (x86)\Windows CE Tools\SDKs\DS-200i\include\ARMv4I\winbase.h(3189) : see declaration of 'CreateSemaphoreW' To make things worse in Windows Mobile 6 SDK half of API is imported and half is not (goes through corelib.lib). Visual Studio 2008 installer includes WM6 SDK. And in the file C:\Program Files (x86)\Windows Mobile 6 SDK\PocketPC\include\ARMV4I\winbase.h there are functions not prefixed with WINBASEAPI. The solution would be to have 2 new defines instead of BOOST_SYMBOL_IMPORT in boost::winapi. On CE 7 both would be empty, on WM 6 one would be __declspec(dllimport) Regards, Vyacheslav

4 3

Yap formally accepted into Boost
by Louis Dionne 04 Jun '18

04 Jun '18

Dear Boost, This message is to announce that Yap (which had been conditionally accepted [1]) is now accepted into Boost, since the conditions for acceptance have been met. The conditions for acceptance were: - Improve the documentation to satisfy Brook Milligan and myself (done) - A single macro for symmetric binary operators (done in https://github.com/tzlaine/yap/issues/22) - Get rid of external dependencies checked into repository (done) - Boost.Build (done in https://github.com/tzlaine/yap/issues/52) Congratulations Zach! Louis Dionne Review manager for Boost.Yap [1]: https://lists.boost.org/boost-announce/2018/03/0540.php

2 1

Re: [boost] [Algorithm] contains(v, 1)
by Jean-Philippe DUFRAIGNE 04 Jun '18

04 Jun '18

On 5/31/18 3:14 AM, Olaf van der Spek via Boost wrote: > Hi, > > vector<int> v; > contains(v, 1); > > This doesn't work as contains expects two ranges (AFAIK). > Is there some other function that's usable for this purpose? > Should contains support a value for argument 2? > > Gr, > Hi, This algorithm exists: boost::any_of_equal https://www.boost.org/doc/libs/1_67_0/libs/algorithm/doc/html/the_boost_alg… Thanks; Jean-Philippe

2 1

[outcome] v2.1 progress report
by Niall Douglas 04 Jun '18

04 Jun '18

Dear Boost, Two months after you accepted Outcome into Boost, I am pleased to say that I believe that all the known bugs and very substantial source refactoring recommended by the peer review have been implemented (detailed changelog is appended below). What remains is a few months of maturing in real world use as all this severe refactoring needs to be tested outside a test suite, and of course the documentation which I don't intend to start work on until the autumn. The Boost edition has, obviously, received a major upgrade and it is now 100% "Boost native" in that it uses Boost.System and Boost.Exception now. The test suite for the Boost edition exclusively tests the Boost native edition, and it all passes. Outcome (both standalone and Boost editions) now can handle both Boost and std types freely intermixed as you see fit. A new "lite" single header edition exists which drags in virtually no system headers, and is hideously low impact on compile times as a result. ABI and API stability have been dumped to git repo with scripting to check the current library against the frozen dumps. This edition should make the corporate crowd very pleased. Very little should appear to have changed from the outside. Code written for v2.0 ought to, more or less, compile and work as before with v2.1. I would appreciate whatever help the Boost community can give in helping to test this edition. I expect new bugs to have been introduced given the severe source code refactoring, and new dual support for Boost and std as equals. My gratitude in advance. Niall --- ## v2.1 in progress [[project]](https://github.com/ned14/outcome/projects/1) - Boost edition is now 100% Boost, so defaults for `result` and `outcome` are `boost::system::error_code::errc_t` and `boost::exception_ptr`. Moreover, the test suite in the Boost edition now exclusively tests the Boost edition. One can, of course, freely use the standalone edition with Boost, and the Boost edition with `std` types. - Renamed ADL discovered customisation point `throw_as_system_error_with_payload()` to `outcome_throw_as_system_error_with_payload()`. - [#135](https://github.com/ned14/outcome/issues/135) - Added much clearer compile failure when user tries `result<T, T>` or `outcome` where two or more types are identical. Thanks to Andrzej Krzemieński for suggesting a technique which combines SFINAE correctness with the remaining ability for `result<T, T>` etc to be a valid type, but not constructible. - [#67](https://github.com/ned14/outcome/issues/67) - Fixed one of the oldest long open bugs in Outcome, that the noexcept unit tests failed on OS X for an unknown reason. - [#115](https://github.com/ned14/outcome/issues/115) - Outcome did not construct correctly from `failure_type`. - Inexplicably outcome's error + exception constructor had been removed. Nobody noticed during the Boost peer review, which is worrying seeing as that constructor is needed for one of the main advertised features to Boost! - [#107](https://github.com/ned14/outcome/issues/107) and [#116](https://github.com/ned14/outcome/issues/116) - `operator==` and `operator!=` now become disabled if the value, error and exception types do not implement the same operator. - Relatedly, both comparison operators simply didn't work right. Fixed. - [#109](https://github.com/ned14/outcome/issues/109) - `swap()` now has correct `noexcept` calculation and now correctly orders the swaps to be whichever is the throwing swap first. - Added reference dump of v2.1 ABI so we can check if ABI breakage detection works in the next set of changes, plus Travis job to check ABI and API compatibility per commit. - [#124](https://github.com/ned14/outcome/issues/124) - `OUTCOME_TRY` is now overloaded and selects `void` or `auto` edition according to input parameter count. - [#120](https://github.com/ned14/outcome/issues/120) - Fix generation of double underscored temporary variables in `OUTCOME_UNIQUE_NAME`, which is UB. - [#110](https://github.com/ned14/outcome/issues/110) - Separated `result` from its hard coded dependency on the `<system_error>` header. - Renamed `result` and `outcome` to `basic_result` and `basic_outcome`. - Renamed `result.hpp` into `basic_result.hpp`. - Moved `<system_error>` and `<exception>` dependent code into new `std_result.hpp` and `std_outcome.hpp` header files. - Added `boost_result.hpp` and `boost_outcome.hpp` which use Boost.System and Boost.Exception (these are `result.hpp` and `outcome.hpp` in the Boost edition). -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

1 1

[beast] How do I select un-DEPRECATED interfaces?
by Brian Kuhl 04 Jun '18

04 Jun '18

Hi Experts, I’m working with an EAR release of VxWorks 7 with llvm v5.0 and VxWorks’ first C++14 STL ( Dinkum v700) and Boost v 1.67 ( Yes, the RTOS world moves slowly) I’ve gotten a clean compile of Beast with #define BOOST_BEAST_ALLOW_DEPRECATED #define BOOST_COROUTINES_NO_DEPRECATION_WARNING But I’m having trouble locating the logic that’s choosing these deprecated interfaces for me? Could someone point out the relevant logic? Many Thanks, Brian Kuhl Senior Manager – Information Development Wind River

2 1

[Algorithm] contains(v, 1)
by Olaf van der Spek 03 Jun '18

03 Jun '18

Hi, vector<int> v; contains(v, 1); This doesn't work as contains expects two ranges (AFAIK). Is there some other function that's usable for this purpose? Should contains support a value for argument 2? Gr, -- Olaf

5 13

[compressed_pair] [hof] [hana] What's the story with compressed_pair?
by Tom Westerhout 30 May '18

30 May '18

Hello! It looks like there are at least three different implementations of a "std::pair with EBO" in Boost: boost/utility/compressed_pair.hpp boost/hof/detail/compressed_pair.hpp boost/hana/pair.hpp Finally, there is also std::tuple which seems to also make use of EBO. I need similar functionality for a GSoC project I'm working on this year. So I'm wondering, is compressed pair considered a simple technicality that should be implemented from scratch every time I need it or shall I stick to one of the four mentioned implementations? I would much prefer to use Boost.Utility's one, but unfortunately it's neither constexpr-friendly nor noexcept-friendly... Is there some reason why it cannot be annotated with macros which expand to constexpr and noexcept when compiled with C++11 support? Or has no one just gotten around to do it? Thanks in advance, Tom

3 3