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

CMake Announcement from Boost Steering Committee
by Jon Kalb 13 Aug '24

13 Aug '24

The libraries produced by the Boost community have had a greater impact on the way that the C++ community writes code than any other library implementation. The focus of the Boost community will always be on the libraries, but it is undeniable that we are dependent on and often limited by the infrastructure of our trade. Years ago, the move to Git was contentious; yet, it was required to improve development. In a similar vein our build system has become an impediment for many developers and users, existing and prospective. Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike. We are soliciting comments and proposals from the community to guide the process and the goals. Our desire is that the community can come to consensus by the end of the calendar year with a vision of supporting users and developers. We understand that the actual process of achieving the end goal will be long, time consuming, and not without its share of conflict. We also recognize that the Boost community is comprised of bright and passionate individuals that are eager to get involved and help get work done. The members of the Steering Committee have been encouraged by the discussions and activity surrounding CMake on the mailing lists over the years and know that many people have voiced visions. We hope that each of you rejoins the discussion to support this initiative and contributes to the common goal of improving Boost’s integration into the broader C++ ecosystem. For the Boost Steering Committee, Jon Kalb, Chair jonkalb(a)boost.org

49 199

[RFC] unique_val (handles, IDs, descriptors...)
by Miguel Ojeda 15 Oct '18

15 Oct '18

Hi all, While working on a medium-sized project, I had to wrap quite some handles, IDs, descriptors, etc. into RAII classes. Somehow, writing those and making them movable seemed more verbose than needed. I searched in the STL and Boost for something already implemented, but nothing seemed to come up. I decided to write my own prototype to see whether I was missing something important; but actually using it in my project felt quite natural and simple. At this point, I asked for a second opinion from a well-known expert (thanks Scott!) and he agreed that it seemed like a reasonable idea but, of course, he would also be surprised if others haven't come up with something similar. So I polished it up a bit and uploaded it to: https://github.com/ojeda/unique_val Below you have the introduction inlined [1]. If you have the time, please take a look (specially to the Rationale) and let me know your comments. The code itself is very short and straightforward. If you already have this class/template in Boost somewhere that I missed, please let me know! Otherwise, if you think this could be interesting to put into Boost in some existing library (not sure which) or as a new tiny library, I would be glad to make the effort to expand it, clean it up, etc. Thank you! Miguel [1] """ A single-header header-only library for representing unique values (handles, IDs, descriptors...) that default to a value on move for C++11, C++14 and C++17. It simplifies writing resource-owning classes (RAII) with move semantics support for resources with handles, IDs or descriptors that are supposed to be used as unique values, not as unique pointers. For instance, it can be used with non-pointer handlers (like the `int` file/socket descriptors in POSIX) and with opaque pointer handlers (like the `HWND` handles in the Win32 API). As such, it can be used as an alternative to `std::unique_ptr` with or without custom deleter, specially for resources that use a non-pointer type or resources that are not simply heap-allocated. It does not have any overhead compared to using the original type. It supports booleans, integers, pointers and enumerations. The default value can be different than the default-constructed value (i.e. different than 0, nullptr, etc.). """

7 13

Original STL Library Documentation has been recovered and is now safe forever.
by Robert Ramey 02 Sep '18

02 Sep '18

The Standard Template Library is the foundation of modern C++. The creation and publication of this code and its documentation set a new standard for the formal specification of what a computer program should do, how it should be designed and how it should be formally documented. These pages were maintained first by Silicon Graphics and then later by Hewett-Packard. In January of 2018 these pages were removed by H-P. This is a historic blunder. I have recovered the original STL Library Document and hosted them here: http://www.rrsd.com/software_development/stl/index.htm Robert Ramey

8 10

Docker environment(s) for Boost Development
by James E. King, III 26 Jul '18

26 Jul '18

I submitted a pull request into the superproject containing some docker scripts. The intention of this is to simplify managing a docker build environment for boost: https://github.com/boostorg/boost/pull/184 I'm wondering if folks will find this useful, and whether folks think this should be in its own submodule instead of being in boostorg/boost. I only have an Ubuntu Bionic environment in this pull request but it wouldn't be that difficult to add debian, centos, and others, as well as various versions of each. I have tested it on Unix and on Windows. On Unix the performance is quite good overall - but on Windows since they use SMB to do the sharing it is really slow (I would say a good 20 times slower between typing "b2" and getting the first output as it scans through all the files. I would recommend continuing to use a virtual machine on Windows Hosts for unix boost development, but this option is there and hopefully they will improve things. This partially came out of the discussion we had a number of months back about how we handle third party dependencies. For the most part one has to look at README files in various locations to learn about them. This is an attempt to pull all the dependencies together for a complete build into one place (the Dockerfile). One day when Microsoft supports Visual Studio compilation inside a reasonably sized windows container (i.e. based on nanoserver and not Windows Server Core), I'd like to add that as well since managing the dependencies on Windows is a bit harder (you usually have to build them). Thanks, Jim

5 8

Boost.Signals deprecation and removal
by James E. King, III 15 Jul '18

15 Jul '18

This first implementation of signals has been deprecated since the 1.54 release. (When) are we going to remove it? It is under management of the CMT, and it has been deprecated for over 10 major releases. I would like to suggest we remove it in the Boost 1.68.0 release. - Jim

9 9

[Build] Create test with shared library linked against current Boost link-variant
by Alexander Grund 18 Jun '18

18 Jun '18

Hi, I discovered a severe bug in Boost.Serialization and am trying to contribute a test to the test suite to reproduce that behavior. I have a minimum example which runs into this (see also https://stackoverflow.com/questions/50064617/order-of-destruction-for-stati…) but I'm having trouble getting that into the Jamfile. What I need: 2 shared libraries linked against the currently tested Boost link-variant and link those into an executable not linked against Boost. So testcase a) would be against Boost-Shared and b) against Boost-Static. But in all cases the libraries itself must be shared. What I have: lib multi_shared_1 : multi_shared1.cpp ../build//boost_serialization : <link>shared ; lib multi_shared_2 : multi_shared2.cpp ../build//boost_serialization : <link>shared ; ... [ test-bsl-run test_multi_shared_lib : : multi_shared_1 multi_shared_2 ] Problem: This links against Boost-Shared even with "./b2 link=static" My best approach so far is to change "../build//boost_serialization" to "../build//boost_serialization/<link>static" but then I cannot test testcase a) (Boost-Shared) anymore. Also it does link other Boost-Libraries (filesystem, system) shared, not static. Furthermore I'd need to add `-fPIC` to the cxxflags of the boost libraries. This is minor as it can be done in the `.travis` file but I'd rather have it in the Jamfile so it is not missed in other test-environments. How can I achieve this? I'm not to familiar with the Jamfiles so this is basically all I could find so far. Thanks, Alexander Grund

1 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

[Hana] "basic_tuple.hpp" bug when building with VS2017
by Louis Dionne 30 May '18

30 May '18

> Hello, > > Just installed Boost and Visual Studio 2017 a few days ago. Visual Studio 2017 is known to be unable to compile Hana (and other libraries such as Range-v3). I will be working with the Microsoft folks to make it work as they explicitly reached out to me with that intent. Cheers, Louis

4 9

[testing][regressions] All my regressions testers failing due to connection errors to GitHub
by Ion Gaztañaga 28 May '18

28 May '18

Hi, All my 4 testers (I have 4 machines running several Mingw targets) are always failing pulling new versions from GitHub. This problem started some days ago. I've tried to reset all machines, network equipment, disabling antivirus, firewall, modified http attributes, modified the regression script to use git protocol instead of https, etc. with no luck. I'm using Windows machines with official Git. Any clue on what's going on? Maybe Github recently does not like so many submodules? Example of failure (several libraries can fail during "git pull "--recurse-submodules""): ------------------- ------------------- ------------------- Fetching submodule libs/io fatal: unable to access 'https://github.com/boostorg/io.git/': OpenSSL SSL_read: SSL_ERROR_SYSCALL, errno 10054 Then: # git_source_checkout failed with message "GIT command "git pull "--recurse-submodules"" failed with code 1" # Retrying (5 more attempts). # Executing GIT command: c:\boost\develop\boost_root> git submodule foreach "git submodule deinit ." ------------------- ------------------- All retries fail and the script fails with error: ------------------- ------------------- ------------------- # git_source_checkout failed with message "GIT command "git pull "--recurse-submodules"" failed with code 1" # Giving up. Traceback (most recent call last): File "run.py", line 71, in <module> runner(root) File "c:\boost\develop\boost_regression_src\regression.py", line 286, in __init__ self.main() File "c:\boost\develop\boost_regression_src\regression.py", line 623, in main getattr(self,action_m)() File "c:\boost\develop\boost_regression_src\regression.py", line 578, in command_regression self.command_get_source() File "c:\boost\develop\boost_regression_src\regression.py", line 330, in command_get_source self.retry(self.git_source_checkout) File "c:\boost\develop\boost_regression_src\regression.py", line 662, in retry return f() File "c:\boost\develop\boost_regression_src\regression.py", line 875, in git_source_checkout self.git_checkout(git_info['boost'], self.git_branch(), clean) File "c:\boost\develop\boost_regression_src\regression.py", line 849, in git_checkout self.git_command( 'pull', '--recurse-submodules' ) File "c:\boost\develop\boost_regression_src\regression.py", line 834, in git_command raise Exception( 'GIT command "%s" failed with code %d' % (git_cli, rc) ) Exception: GIT command "git pull "--recurse-submodules"" failed with code 1 END 24/05/2018 15:28:37,46 ------------------- ------------------- ------------------- Errors are never in the same libraries, very few times the checkout succeeds and a regression is run. Anyone else having these problems? I've attached the log of one failure in case someone can see any clue. I really don't see how to solve this, so I won't be able to run regressions. Best, Ion

3 4

GCC versions
by Ian Emmons 28 May '18

28 May '18

Apologies if this is off topic, but the audience here is perfect for this question: I need to support CentOS version 7 with my C++ software. The version of GCC that is supported out-of-the-box on that version of Linux is rather old -- it supports C++11, but not C++14, and of course I would like to use a newer standard. Is it common practice on Linux to install a later version of GCC than the out-of-the-box on version? If so, how do you handle the run-time shared library dependencies? Any pointers would be helpful. Thanks, Ian

3 2

Boost multiprecision differential fuzzer running on Google's oss-fuzz
by Guido Vranken 28 May '18

28 May '18

Dear list, I built a bignum differential fuzzer [1] that has been running on Google's oss-fuzz service [2] for a while. It performs the same mathematical operations (addition, subtraction, multiplication, modular exponentation, etc) across multiple bignum libraries (eg. OpenSSL + Boost multiprecision), compares their results and crashes if they don't match. This effort has so far found a couple of (minor) bugs in OpenSSL and Go. As soon as a mismatch is found, oss-fuzz will send a notification e-mail to the developers of the various bignum libraries so the bug can be examined and resolved. At which e-mail address(es) do the developers of Boost wish to receive these notifications? Please bear in mind that the notifications will contain potentially security-sensitive information so the recipient may not be a public mailing list. Currently, a potential bug is found only every couple of weeks, so recipients do not have to worry about a lot of incoming traffic. If you wish to write comments to the fuzzer's private bug tracker, the e-mail you specify must be linked to a Google account. To all others who are reading this, please feel welcome to submit pull requests to the Boost multiprecision module of my fuzzer [3] if these modifications increase the scope (code coverage) and probability of finding bugs. Thanks, Guido [1] https://github.com/guidovranken/bignum-fuzzer [2] https://github.com/google/oss-fuzz [3] https://github.com/guidovranken/bignum-fuzzer/tree/master/modules/cpp_boost

2 1

[windows] Wni32/Vigorf.A trojan in boost_1_67_0-msvc-14.1-64.exe?
by Mateusz Loskot 28 May '18

28 May '18

Hi, One user reported via #boost at cpplang.slack.com that Windows Defender reported trojan in the latest Windows binaries. I checked myself and I can confirm the latest up-to-date Windows Defender is detecting Vigorf.A in the installer archive. Is this false report? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

5 7

Boost.DisjointSets and Boost.Container
by James E. King, III 27 May '18

27 May '18

Currently the disjoint_sets repository ( https://github.com/boostorg/disjoint_sets) holds a single class in "boost/pending" that is only used by the graph and graph_parallel projects (that I can tell...). I'd like us to consider taking disjoint_sets out of pending state and make it official as part of Boost Containers. Both Graph and GraphParallel require linking already, and they may already use Boost.Containers (I haven't checked). disjoint_sets is header-only however and this might cause problems for anyone relying on it, however since it's in boost/pending, I wonder if anyone is actually using it. Given the pending designation on it however, a breaking change seems reasonable to me. It will reduce the burden on the CMT, and container has at least some CI on it already. Thoughts? - Jim

1 0

[SPAM]
by Scott Karns 25 May '18

25 May '18

http://follow.anthologypaper.com Scott Karns

1 0

Interest in a tiny kmeans library
by Raffi Enficiaud 23 May '18

23 May '18

Dear all, We are finishing the cleanup of a tiny kmeans library. For those who do not know, kmeans is a widely used data clustering algorithm. This special implementation has a lower runtime complexity by taking advantages of the triangle inequalities between clusters and data points at each iteration. This implementation is based on the paper of Charles Elkan https://www.aaai.org/Papers/ICML/2003/ICML03-022.pdf We have also python and matlab bindings, fully generic on the data type, and with additional initialization heuristics. I would be happy if we can release this library into Boost. Do you think there is any interest for the community? Best regards, Jean-Claude Passy and Raffi Enficiaud

5 5

PR: Remove safe_bool idiom from boost.tribool
by Robert Ramey 22 May '18

22 May '18

Removed usage of "safe_bool" idiom from tribool. This was initially motivated by the fact that usage of this idiom with all current and past gcc compilers with constexpr does not work. First it reports reference to the address of a local member function as not being constexpr. This may or may not be correct according to the standard. FWIW clang is OK with it. Making the member function constexpr fixes this error. But still there is a problem. in GCC, the operator to implicitly covert the instance to a void * does not seem to work. Invocation of this operator in the context of an argument to an if(... or other conditional doesn't result in behavior similar to bool. Not even a static cast to a bool seems to work. Again CLANG is OK with all this. This has been reported as an issue to the GCC team. One idea which has been tried is to use C++11 "explicit" as a substitute from the safe_bool idiom. Unfortunately this breaks legacy code. bool f(x) { return tribool(true); // fails } So this is not a great solution either. Attempts to resolve this were inconclusive. This motivated me to think about why the safe_bool idiom was being used here at all. According to articles on safe_bool articles this main reason is to support the common practice of using a not null value in a conditional: Testable t; if(t) ... without accidentally permitting things like if(t >> 1)... The above would occur if Testable included an operator bool () const member function. Basically safe_bool is meant to support the common C/C++ practice of implicity converting something to bool so we write something like if(t) ... to mean t "is_valid" or "is_not_null" or some such. a) I don't think this idiom is a good idea and even more so in the context of modern C++. Conversion of a Testable instance to a bool instance should result in something that looks/acts like a C bool - not something else like a void * which C then maps to a bool. If we want to use a bool for something like "is_valid" we'd be much better off just implementing is_valid directly. There would be then no confusion, side effects or hand a waving. b) it's an especially a bad idea for tribool. The motivating concept behind tribool is that of some sort of "extended" bool. The naming suggests that it acts like a bool. But since we've used he safe_bool idiom, it doesn't any more. That is we can't use a tribool anywhere a bool is used. So if we use operator bool we'll get a tribool which acts like a bool - even when the original usage of bool was a bad idea according to a) above. But at least we have the same behavior for tribool and bool which is a lot more intuitive and less confusing. Also, changing to operator bool () will address the current problem with GCC not supporting a constexpr version of tribool. Accordingly, I've submitted this PR to change the implementation of tribool to avoid the safe_bool idiom.

7 22

FWD: [cfe-users] Boost.GIL test failing with clang 5.x while pass with 15 gcc/clang versions
by Mateusz Loskot 21 May '18

21 May '18

Hi, I posted this to clang mailing list a http://lists.llvm.org/pipermail/cfe-users/2018-May/001335.html but since it is related to Boost.GIL bugs I'm investigating, I'd like to reach for feedback here too. I'll appreciate any comments regarding the issue explained below. ML ---------- Forwarded message ---------- From: Mateusz Loskot <mateusz(a)loskot.net> Date: 19 May 2018 at 21:38 Subject: Boost.GIL test failing with clang 5.x while pass with 15 gcc/clang versions To: cfe-users(a)lists.llvm.org Hi, While testing Boost.GIL library [1] with gcc and clang, I noticed a peculiar issue. One particular test is failing with lang 5.x while passing with total of 15-17 other versions of clang and GCC (total workflow of CircleCI with at [2]). Below is extracted minimal program equivalent to Boost.GIL channel_invert algorithm. It includes two variants: plain expression and the same expression wrapped with a function template: #include <limits> #include <iostream> #include <typeinfo> template <typename C> inline C channel_invert1(C x) { return std::numeric_limits<C>::max() - x + std::numeric_limits<C>::min(); } template <typename C> inline C channel_invert2(C x) { return (x - std::numeric_limits<C>::max()) * (-1) + std::numeric_limits<C>::min(); } int main() { int x = std::numeric_limits<int>::min(); std::cout << x << std::endl; // plain expressions int x_invert1 = std::numeric_limits<int>::max() - x + std::numeric_limits<int>::min(); int x_invert2 = (x - std::numeric_limits<int>::max()) * (-1) + std::numeric_limits<int>::min(); std::cout << x_invert1 << std::endl; std::cout << x_invert2 << std::endl; // the same expressions wrapped in function template std::cout << channel_invert1<int>(x) << std::endl; std::cout << channel_invert2<int>(x) << std::endl; } If compiled as optimised variant (-O2 or -O3) with clang 5.x outputs the following: -2147483648 2147483647 2147483647 -1 -1 The last two negative one is not expected. If compiled with clang 3.9, 4.0 or gcc from 5.1 to 7.3 it outputs -2147483648 2147483647 2147483647 2147483647 2147483647 Could anyone help me to understand what is going on in the clang 5 case? Or, what UB is this hitting? [1] https://github.com/boostorg/gil/issues/89 [2] https://circleci.com/workflow-run/3a14dd64-6c38-46b2-a6da-678c0075ca27 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 1

Enabling issues on boostorg/mpi
by Alain Miniussi 21 May '18

21 May '18

Hi, Could somebody with the sufficient permissions enable issues on the github mpi repository ? Thanks Alain Miniussi

2 2

Proposal for a thread synchronisation primitive: future_queue
by Martin Hierholzer 21 May '18

21 May '18

Dear boost developers, I want to propose a thread synchronisation primitive, which works like a mixture of (lockfree) queues and futures. Therefore I gave it the name "future_queue". It is basically a lockfree queue which can be waited on for new values (without busy waiting), but it has some nice extra features like when_any() and continuations. The github project can be found here: https://github.com/mhier/future_queue It already contains a README file with a short description, an example and results of a first performance measurement. Further documentation so far exists only inside the code: https://github.com/mhier/future_queue/blob/master/include/future_queue.hpp My first question is, whether this is really something new (I might have overlooked something in the many boost libraries) and if it makes sense to integrate it into the boost libraries. Another question would be whether this should really be its own library, since it is basically a single class (with a few helper classes) and a single non-member function. Maybe it would be better to make it part of an existing library? I am happy to receive some first feedback! Cheers, Martin -- Martin Hierholzer DESY Notkestrasse 85 22607 Hamburg Office 55a / 123 Tel: +49 40 8998 1897 Mob: +49 176 992 46 476 Skype: mhier48 This e-mail may contain confidential and/or privileged information and is intended only for the use of the individual or entity named above. If you received it in error, please advise the sender immediately by reply e-mail and delete the original. Any further use - especially any form of publication - of this e-mail without explicit authorisation is strictly prohibited.

4 11

[Hana] "basic_tuple.hpp" bug when building with VS2017
by Daniel Chen 20 May '18

20 May '18

Hello, Just installed Boost and Visual Studio 2017 a few days ago. Here is a bug when building with Hana's "basic_tuple.hpp" header with Visual Studio 2017: In basic_tuple.hpp: template <> struct drop_front_impl<basic_tuple_tag> { template <std::size_t N, typename Xs, std::size_t ...i> static constexpr auto drop_front_helper(Xs&& xs, std::index_sequence<i...>) { return hana::make_basic_tuple( detail::ebo_get<detail::bti<i+N>>(static_cast<Xs&&>(xs))... ); } template <typename Xs, typename N> static constexpr auto apply(Xs&& xs, N const&) { constexpr std::size_t len = detail::decay<Xs>::type::size_; return drop_front_helper<N::value>(static_cast<Xs&&>(xs), std::make_index_sequence< N::value < len ? len - N::value : 0 >{}); //<Bug here - line 197 of basic_tuple.hpp } }; Upon building with "basic_tuple.hpp", the line highlighted in green reports an error: "syntax error: unexpected token ')', expected 'id-expression'". Focus on the line above that one: N::value < len ? len - N::value : 0 If you add parentheses, the error goes away: (N::value < len) ? len - N::value : 0 A similar bug occurs - and is fixed likewise - in the "string.hpp" header file at line 275, that is: template <> struct drop_front_impl<string_tag> { ... template <char ...xs, typename N> static constexpr auto apply(string<xs...> const& s, N const&) { return helper<N::value>(s, std::make_index_sequence< N::value < sizeof...(xs) ? sizeof...(xs) - N::value : 0 >{}); //<bug here - line 275 of string.hpp } I'm not sure if this is a Microsoft compiler issue (I will post to them as well), but I feel like someone should add those parentheses (and then some) to the line since it is safer - the "<" can be easily confused for a template bracket instead of a less-than sign by a parser. Daniel Chen Infinera

2 1

Boost.Test, cygwin, and ISO/POSIX
by James E. King, III 19 May '18

19 May '18

Hello, I have been adding some CI infrastructure to the CMT repositories and found I am able to reproduce a failure building boost libraries that use Boost.Test for their unit tests. If you build with "cxxstd=03" you can get to some undefined functions. See: https://github.com/boostorg/test/issues/144 It looks like one needs to define _POSIX_C_SOURCE=200112L or cxxstd-dialect=gnu in order for these functions to become visible. I was thinking of addressing this two ways: 1. I want to change boost build (bjam) to define _POSIX_C_SOURCE when building on cygwin to this value if it is not otherwise defined. I can't find the right place to add this. 2. I don't think it's reasonable for Boost.Test to modify _POSIX_C_SOURCE since it could be included after sys/functional header, so I would like to either change Boost.Test so it does not depend on these three functions, or check to see if the right preprocessor definitions are set on cygwin and put up a better error message, or simply change the documentation and update all the CI build scripts in all the affected repositories to set _POSIX_C_SOURCE as part of the CI build. Any thoughts or other ideas on this? Thanks, Jim

1 0

disjoint_sets repo status
by James E. King, III 17 May '18

17 May '18

What is the current status of https://github.com/boostorg/disjoint_sets ? The headers appear to be in a "pending" state. There's almost nothing in this repo. Perhaps it was put here to solve a circular dependency issue? It looks like it is used by graph and graph_parallel. Could we move this into Boost.Algorithm? Thanks, Jim

1 0

[release][chrono] libs/chrono/stopwatches/include not in boost/chrono/stopwatches
by Andrey Semashev 17 May '18

17 May '18

Hi, In the 1.67 released archive, there is libs/chrono/stopwatches/include directory that contains headers that look like they should be placed in boost/chrono/stopwatches. With the checkout from git, `b2 headers` create links boost/chrono/stopwatches and boost/chrono/stopwatches.hpp that refer to that directory. Looks like the packaging scripts need to be updated.

2 1

dynamic_bitset needs some attention
by James E. King, III 16 May '18

16 May '18

I have been adding a common CI infrastructure to the CMT repositories. Occasionally I have to disable one or two build jobs to get a clean build and I file an issue. When I got to dynamic_bitset however, there's clearly something going on in there and it isn't good. I think it has to do with streaming. It's probably just one issue causing most of the failures. You can see the results from my latest dry-run PR here: https://github.com/jeking3/dynamic_bitset/pull/1 Right now both the main travis and all of the appveyor builds are failing, and they all look like they get stuck on test 4 in iostream processing. Something just isn't right in there - it could be the test itself or it could be something else. I may submit a PR into the repo for the CI additions anyway even if they are failing, since it points out this component has rotted and needs attention. Also if my PRs in pool and function can be merged, we'll have better CI on those. Aiming to get all the CMT repos covered with appveyor, travis, codecov, and eventually covscan. - Jim

1 0

Clarifying Boost evolution plans mentioned on Twitter
by Bryce Adelstein Lelbach aka wash 16 May '18

16 May '18

Hi all, Some pictures from the C++Now "Boost Library In A Week" end-of-week summary were posted to Twitter today by an attendee, along with some mistaken statements suggesting that "Boost plans to move to C++11". I want to clarify what is actually going on: 0.) During the week, the Library In A Week group discussed some ideas for how Boost might migrate to newer standards. I'm somewhat to blame as I initiated these discussions. 1.) Those ideas were collected into a draft document by Jeff Garland. 2.) During the closing panel, Jeff presented the draft document and stated the next step would be to share it with the mailing list. 3.) Due to an innocent misunderstanding, an attendee posted a picture of part of the document with the unclear message "Boost plans to move to C++11". 4.) I wrote this email. I have asked the attendee to delete the tweet (and repost with a clearer message if they wish). I don't want to share the document from LIAW. Jeff put a lot of work into it and I don't want to steal his thunder (I realize this email inevitably does that). I'm sure he will follow up with a post explaining what ideas we came up with soon. I'm very sorry for the confusion, and I'm sure the attendee is as well. This was just an innocent mixup. ------------------------------------------------------ Bryce Adelstein Lelbach aka wash ISO C++ Committee Member CppCon and C++Now Program Chair Thrust Maintainer, HPX Developer CUDA Convert and Reformed AVX Junkie Sleep is for the weak ------------------------------------------------------

4 3

[interprocess]Request to support wchar_t* file name on Windows
by 孙朝阳 15 May '18

15 May '18

Hi, I'm using boost.interprocess.file_mapping on Windows, and I need to use it to open files with localized file path, so I want file_mapping can support wchar_t file name on Windows. Does any reason prevent file_mapping to support wchar_t file name? If no, would someone like to add wchar_t supporting for file_mapping? I also created a pull request for this: https://github.com/boostorg/interprocess/pull/28 Thanks, Jackson Sun

1 0

boost libs compiled for gcc toolset with boost 1.67 and CMake 3.11 won't find libs
by Demetri Kopsas 12 May '18

12 May '18

Hi, I discovered that the latest version of boost does not work with CMake when using the GCC toolset. I submitted this bug: https://gitlab.kitware.com/cmake/cmake/issues/17974#note_408614 Using MSVC as the toolset is fine on windows, but using mingw (gcc compiler) cannot find the libs unless I take out ‘x32’ or ‘x64’ from the name after compilation.

2 1

[build] recent issues w. VS 2017
by Raffi Enficiaud 12 May '18

12 May '18

Dear all, I am experiencing an issue with VS 2017 (15.6.6) while compiling boost.test on my agent. Traces below. I do not recall having applied any change to this agent apart from installing C++/CLI support for CMake people. Is this problem known? Thanks, Raffi build 01-May-2018 11:43:49 D:\bamboo_build_dir\SW-BCB161-VC2017WIN\library\libs\test\test>..\..\..\b2 --abbreviate-paths toolset=msvc-14.1 cxxflags="/std:c++latest" build 01-May-2018 11:43:50 Performing configuration checks build 01-May-2018 11:43:50 build 01-May-2018 11:43:50 - default address-model : 32-bit (cached) build 01-May-2018 11:43:50 - default architecture : x86 (cached) build 01-May-2018 11:43:50 - symlinks supported : no (cached) build 01-May-2018 11:43:50 - junctions supported : yes (cached) build 01-May-2018 11:43:50 - hardlinks supported : yes (cached) build 01-May-2018 11:43:51 - BOOST_COMP_GNUC >= 4.3.0 : no build 01-May-2018 11:43:54 - Boost.Config Feature Check: cxx11_auto_declarations : no build 01-May-2018 11:43:54 - Boost.Config Feature Check: cxx11_function_template_default_args : no build 01-May-2018 11:43:54 - Boost.Config Feature Check: cxx11_lambdas : no build 01-May-2018 11:43:55 - Boost.Config Feature Check: cxx11_hdr_initializer_list : no build 01-May-2018 11:43:55 - Boost.Config Feature Check: cxx11_template_aliases : no build 01-May-2018 11:43:55 - Boost.Config Feature Check: cxx11_decltype : no build 01-May-2018 11:43:55 - Boost.Config Feature Check: cxx11_hdr_random : no build 01-May-2018 11:43:55 - Boost.Config Feature Check: cxx11_hdr_tuple : no build 01-May-2018 11:43:55 - Boost.Config Feature Check: cxx11_variadic_macros : no build 01-May-2018 11:43:55 - Boost.Config Feature Check: cxx11_trailing_result_types : no build 01-May-2018 11:43:56 - Boost.Config Feature Check: cxx11_nullptr : no build 01-May-2018 11:43:56 - Boost.Config Feature Check: cxx11_unified_initialization_syntax : no build 01-May-2018 11:43:56 - Boost.Config Feature Check: cxx11_variadic_templates : no build 01-May-2018 11:43:57 - Boost.Config Feature Check: cxx11_decltype : no build 01-May-2018 11:43:57 - Boost.Config Feature Check: cxx11_hdr_random : no build 01-May-2018 11:43:57 - Boost.Config Feature Check: cxx11_hdr_tuple : no build 01-May-2018 11:43:57 - Boost.Config Feature Check: cxx11_hdr_initializer_list : no build 01-May-2018 11:43:57 - Boost.Config Feature Check: cxx11_variadic_macros : no build 01-May-2018 11:43:57 - Boost.Config Feature Check: cxx11_trailing_result_types : no build 01-May-2018 11:43:57 - Boost.Config Feature Check: cxx11_template_aliases : no build 01-May-2018 11:43:57 ...patience... build 01-May-2018 11:43:57 ...found 3946 targets... build 01-May-2018 11:43:57 ...updating 553 targets... build 01-May-2018 11:43:58 compile-c-c++ ..\..\..\bin.v2\libs\test\test\string_cast-test.test\msvc-14.1\dbg\thrd-mlt\utils-ts\string_cast-test.obj build 01-May-2018 11:43:58 string_cast-test.cpp build 01-May-2018 11:43:58 D:\bamboo_build_dir\SW-BCB161-VC2017WIN\library\boost/config/detail/select_stdlib_config.hpp(18): fatal error C1083: Cannot open include file: 'cstddef': No such file or directory build 01-May-2018 11:43:58 build 01-May-2018 11:43:58 call "..\..\..\bin.v2\standalone\msvc\msvc-14.1\msvc-setup.bat" >nul build 01-May-2018 11:43:58 cl /Zm800 -nologo @"..\..\..\bin.v2\libs\test\test\string_cast-test.test\msvc-14.1\dbg\thrd-mlt\utils-ts\string_cast-test.obj.rsp" build 01-May-2018 11:43:58 build 01-May-2018 11:43:58 ...failed compile-c-c++ ..\..\..\bin.v2\libs\test\test\string_cast-test.test\msvc-14.1\dbg\thrd-mlt\utils-ts\string_cast-test.obj... build 01-May-2018 11:43:58 compile-c-c++ ..\..\..\bin.v2\libs\test\build\msvc-14.1\dbg\lnk-sttc\thrd-mlt\compiler_log_formatter.obj

3 5

new b2 property or new boost library?
by Oliver Kowalke 11 May '18

11 May '18

Hi, boost.fiber provides some rudimentary NUMA support. NUMA specific OS APIs require the native thread handle (native_handle_type std::thread::native_handle()). But unfortunately the returned type does not match in all cases the OS handle type. For instance MinGW-W64 using the POSIX thread impl returns long long instead of void*. A solution would be to add an additional b2 property like `numa=on` that compiles the NUMA related part of boost.fiber if set (the user is responsible to compile boost with the appropriate properties). Or the NUMA related code is move from boost.fiber into a complete new boost library. What would be you advice? Oliver

1 0

[type_traits] revisiting is_virtual_base_of
by John Maddock 10 May '18

10 May '18

There is a problem with is_virtual_base_of in that it doesn't work especially well - most of the time it works OK, but can be made to fail catastrophically in a few situations, see for example: https://svn.boost.org/trac10/ticket/11323 Now... it turns out that with C++14 and later we now have is_detected which can test the validity of almost any expression... and I'm wondering if there's a cunning way to press this into action to create a more accurate is_virtual_base_of, but I'm having trouble coming up with anything. Any bright ideas? Note that an explicit static_cast can't be tested for, though we can use is_constructible if required. Thanks in advance, John. --- This email has been checked for viruses by AVG. http://www.avg.com

2 3

build failure in develop: chrono, type_traits?
by James E. King, III 08 May '18

08 May '18

The only change in my pull request was to remove a deprecated, unrelated header in uuid. This happened in the builds last night on develop: In file included from ./boost/config.hpp:61:0, from ./boost/chrono/config.hpp:15, from ./boost/chrono/detail/inlined/process_cpu_clocks.hpp:15, from libs\chrono\src\process_cpu_clocks.cpp:17: ./boost/type_traits/detail/common_arithmetic_type.hpp:209:27: error: duplicate 'const' BOOST_STATIC_CONSTANT(const int, selector = sizeof(select(cond() ? T() : U()))); ^ "x86_64-w64-mingw32-g++.exe" -std=c++03 -m64 -O0 -fno-inline -Wall -pedantic -g -Wextra -Wno-long-long -DBOOST_ALL_NO_LIB=1 -DBOOST_All_STATIC_LINK=1 -DBOOST_SYSTEM_STATIC_LINK=1 -I"." -c -o "bin.v2\libs\chrono\build\gcc-mingw64\debug\cxxstd-03-iso\link-static\process_cpu_clocks.o" "libs\chrono\src\process_cpu_clocks.cpp" ...failed gcc.compile.c++ bin.v2\libs\chrono\build\gcc-mingw64\debug\cxxstd-03-iso\link-static\process_cpu_clocks.o... Failed on cygwin and mingw builds: https://ci.appveyor.com/project/jeking3/uuid-gaamf/build/1.0.116-develop/jo… Also failed in c++03 builds on unix: https://travis-ci.org/boostorg/uuid/jobs/376161574#L2158 gcc.compile.c++ ../../bin.v2/libs/chrono/build/gcc-7/release/cxxstd-03-iso/link-static/thread_clock.o In file included from ../../boost/config.hpp:61:0, from ../../boost/chrono/config.hpp:15, from ../../boost/chrono/detail/inlined/thread_clock.hpp:14, from ../../libs/chrono/src/thread_clock.cpp:18: ../../boost/type_traits/detail/common_arithmetic_type.hpp:209:27: error: duplicate ‘const’ BOOST_STATIC_CONSTANT(const int, selector = sizeof(select(cond() ? T() : U()))); ^ "g++-7" -std=c++03 -m64 -O3 -finline-functions -Wno-inline -Wall -pedantic -Wextra -Wno-long-long -DBOOST_ALL_NO_LIB=1 -DBOOST_All_STATIC_LINK=1 -DBOOST_SYSTEM_STATIC_LINK=1 -DNDEBUG -I"../.." -c -o "../../bin.v2/libs/chrono/build/gcc-7/release/cxxstd-03-iso/link-static/thread_clock.o" "../../libs/chrono/src/thread_clock.cpp" ...failed gcc.compile.c++ ../../bin.v2/libs/chrono/build/gcc-7/release/cxxstd-03-iso/link-static/thread_clock.o... Thanks, Jim

2 1

[filesystem] and C++17 std::filesystem
by Egor Pugin 07 May '18

07 May '18

Hi! gcc8.1 and VS15.7 (2017) are now shipped with std::filesystem. I'd like to raise a discussion about pure c++ interoperability with boost(::filesystem). With boost-1.67 it's not possible to do such things: #if __has_include(<filesystem>) #include <filesystem> namespace fs = std::filesystem; #else #include <boost/filesystem.hpp> namespace fs = boost::filesystem; #endif Because of boost::filesystem::copy_option::overwrite_if_exists != std::filesystem::copy_options::overwrite_existing, std::fs::path() / boost::fs::unique_path(), directory iterators etc. Next, if we take boost::process, for example, we see that it currently operates only on boost::filesystem. If my application uses c++17 fs, I have to write something like this: fs::path f(fs::path in) { bp::search_path(in.u8string()).wstring(); } So, mixing pure c++ and boost becomes more complex. Any ideas how to deal better with such issues on the user side? What are directions of proper fixing this in boost::process (in case I'll try to prepare a PR)? What are boost policies in adopting standard features in general? -- Egor Pugin

2 1

Boost Graph Library(biconnected_components) issue
by Meghana.M Reddy 06 May '18

06 May '18

Hi, I am working on the Boost Graph Library, currently trying to create an interface of the biconnected_components method to a Python code. I used the example code available here <https://www.boost.org/doc/libs/1_67_0/libs/graph/example/biconnected_compon…> for the method and modified it for my purpose. The template of the method is here <https://www.boost.org/doc/libs/1_67_0/libs/graph/doc/biconnected_components…>. The final code seems fine but I get an error while compiling it. And the errors are related to adjacency.hpp which I have not changed so I'm confused as to what the exact problem is. Hoping someone can help me out. My code: class BoostGraph { private: typedef typename boost::adjacency_list< OutEdgeListS, VertexListS, DirectedS, boost::property<boost::vertex_index_t, v_index>, EdgeProperty, boost::no_property, EdgeListS> adjacency_list; typedef typename boost::property_map<adjacency_list, boost::edge_index_t>::type components; public: adjacency_list graph; std::vector<v_index> bc_tree() { components components_bc = get(boost::edge_index, graph); std::size_t num_comps = biconnected_components(graph, components_bc); std::cerr << "Found " << num_comps << " biconnected components.\n"; std::vector<vertex_descriptor> art_points; articulation_points(graph, std::back_inserter(art_points)); std::cerr << "Found " << art_points.size() << " articulation points.\n"; std::vector<v_index> to_return; return to_return; } The error I'm getting: build/cythonized/sage/graphs/base/boost_graph.cpp:3730:26: required from here /home/meghana/Documents/sage_gsoc/sage_may/sage/local/include/boost/graph/detail/adjacency_list.hpp:2696:29: error: forming reference to void typedef value_type& reference; ^ /home/meghana/Documents/sage_gsoc/sage_may/sage/local/include/boost/graph/detail/adjacency_list.hpp:2697:35: error: forming reference to void typedef const value_type& const_reference; ^ /home/meghana/Documents/sage_gsoc/sage_may/sage/local/include/boost/graph/detail/adjacency_list.hpp:2701:61: error: forming reference to void typename Graph::vertex_descriptor,Property,Tag> type; ^ /home/meghana/Documents/sage_gsoc/sage_may/sage/local/include/boost/graph/detail/adjacency_list.hpp:2704:68: error: forming reference to void typename Graph::vertex_descriptor,const Property, Tag> const_type; ^ error: command 'gcc' failed with exit status 1 Makefile:33: recipe for target 'sage' failed make: *** [sage] Error 1 Thank you, Meghana

1 0

Fw: Mysterious Boost.System-related errors when running Beast tests
by Peter Dimov 05 May '18

05 May '18

The story starts with https://travis-ci.org/vinniefalco/beast/jobs/375049193 which gives the error dyld: Symbol not found: __ZN5boost6system6detail19system_category_ncxEv Referenced from: /Users/travis/build/vinniefalco/boost-root/bin.v2/libs/beast/test/beast/core/clang-darwin-4.2.1/debug/threadapi-pthread/threading-multi/fat-tests Expected in: /usr/local/lib/libboost_system.dylib boost::system::detail::system_category_ncx is a new function (in develop), and careful reading of the above reveals that the compiler is trying to link to a preinstalled libboost_system.dylib, in /usr/local/lib. Looking at the log, Boost.System is not even being built. This is odd; the Beast root Jamfile contains <library>/boost/system//boost_system (at https://github.com/boostorg/beast/blob/develop/Jamfile#L78) but even if it didn't, it also links to Filesystem, which _is_ being built, and Filesystem also depends on System in its build/Jamfile: https://github.com/boostorg/filesystem/blob/develop/build/Jamfile.v2#L29 So Boost.System should be built, but it isn't. Its Jamfile hasn't been touched in 10 years: https://github.com/boostorg/system/blob/develop/build/Jamfile.v2 In addition, there's not even a `mklink-or-dir boost/system` in the log, even though the link must be created because the new headers are being used (this could be a separate issue). The Linux/g++ job, https://travis-ci.org/vinniefalco/beast/jobs/375049187, also doesn't seem to build Boost.System, but it works for some reason. When I try `b2 libs/beast/test` on Windows, with msvc-14.1, Boost.System is being built, in the very beginning: ...patience... ...patience... ...patience... ...found 6992 targets... ...updating 1090 targets... link.hardlink ..\..\boost\utility\string_view.hpp Hardlink created for ..\..\boost\utility\string_view.hpp <<===>> ..\utility\include\boost\utility\string_view.hpp compile-c-c++ ..\..\bin.v2\libs\beast\test\beast\core\type_traits.test\msvc-14.1\debug\threadapi-win32\threading-multi\type_traits.obj type_traits.cpp compile-c-c++ ..\..\bin.v2\libs\beast\test\beast\core\type_traits.test\msvc-14.1\debug\threadapi-win32\threading-multi\main.obj main.cpp compile-c-c++ ..\..\bin.v2\libs\system\build\msvc-14.1\debug\threading-multi\error_code.obj error_code.cpp msvc.link.dll ..\..\bin.v2\libs\system\build\msvc-14.1\debug\threading-multi\boost_system-vc141-mt-gd-x32-1_66.dll (The 1.66 version instead of 1.68 was caused by a typo in the superproject which is now fixed.) When I try the same on Ubuntu Trusty, the result is the same as on Travis; no `mklink-or-dir boost/system`, no building of Boost.System, yet everything compiles and works, and I don't have a preinstalled Boost on my VM. It makes no sense at all. Does anyone have any ideas what might be happening here?

1 1

[release][website] Help wanted
by Daniel James 01 May '18

01 May '18

Hello all, For the last couple of releases, I've been handling the releases mostly on my own, but I'm starting a new job and I'm going to have a lot less time, or maybe even no time, for Boost. So we really need more people helping with release management and updating the website. The main release manager responsibilities are described here: https://svn.boost.org/trac10/wiki/ReleasePractices/ManagerCheckList It's probably best if there are a few people involved. I don't think all of them will need admin permissions. For updating the website, you mainly need to occasionally edit html/quickbook files, accept pull requests to the release notes, and use the php scripts to updates the site at release time (I should be able to help a little there). thanks, Daniel

6 5