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

[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