- Boost - lists.preview.boost.org

Guidence on #pragma once
by Robert Ramey 25 Nov '18

25 Nov '18

In the safe numerics library my *.hpp files start with the following boiler plate: #ifndef BOOST_NUMERIC_AUTOMATIC_HPP #define BOOST_NUMERIC_AUTOMATIC_HPP // MS compatible compilers support #pragma once #if defined(_MSC_VER) && (_MSC_VER >= 1020) # pragma once #endif ... I would like to replace all this in every file with just #pragma once according to https://en.wikipedia.org/wiki/Pragma_once#cite_note-9 this should be possible while supporting almost all which claim to be C++ 14 conformant. The exception noted is C++ for Cray. I realize that strictly speaking I shouldn't do this. But it would instantaneously remove some cruft from my code as long as the occasional error from repeating the same include guard text in multiple files. It might have some performance benefits and some other repercussions related to pre-compiled headers. Who knows what else. It would be interesting to know what others might have to say about this. Robert Ramey

10 10

[Boost][DoubleEnded] Status?
by degski 25 Nov '18

25 Nov '18

We had the review of this library proposal/addition quite a while back and ever since I've been [eagerly] waiting for its official entry into Boost. https://github.com/erenon/double_ended does not show any activity and there is nothing in the Boost.Container going on either. What is the status? degski -- *“If something cannot go on forever, it will stop" - Herbert Stein*

4 6

Geometry path length breaking windows regression runs
by Tom Kent 23 Nov '18

23 Nov '18

There has been a change to the geometry library, sometime around Nov 14, that is causing the windows regression runners I manage to crash. The issue is that it is creating *very* long filesystem paths, even with the regression --abbreviate-paths option set. There are a bunch of files such as: D:\teeks99-08\run\results\boost\bin.v2\libs\geometry\test\self_contained_headers\self-contained-algorithms-detail-buffer-buffered_piece_collection~hpp.test\msvc-14.1\dbg\adrs-mdl-64\async-excpt-on\thrd-mlt\self-contained-algorithms-detail-buffer-buffered_piece_collection~hpp.obj.rsp That seem to be created alright, but when I try to cleanup the run afterwards, windows doesn't allow me to delete the files. Tom

5 4

Help - my disk is full! (of bin.v2 stuff)
by Paul A. Bristow 21 Nov '18

21 Nov '18

I note with surprise (and alarm) that my Boost-stuff disk partition is nearly full! Closer inspection reveals that I have a bin.v2 folder of over 50 GB. Obviously, I need to delete something. What are the implications of deleting things? What is the best option? Should I simply delete the whole folder bin.v2 (I have, in desperation, gone nuclear some time ago) or just bin/v2/libs or ? Expert advice welcome. Thanks Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

5 4

Rotating on-call review managers
by Zach Laine 19 Nov '18

19 Nov '18

Boost was originally created to incubate libraries that target eventual standardization. When new libraries are proposed, many of the Boost community members that participate in C++ Standard Committee (WG21) meetings ask "How many users does this have, and did you consider Boost first?" Often the answer is that they considered Boost but could not figure out what they were supposed to do to make that happen, or that they had difficulty finding a review manager. There are other things that can be done to make getting a library Boost-review-ready, but most of them require a bit of work up front. The review manager requirement is relatively easier to satisfy. This volunteer effort is to better facilitate Boost's value in the ISO C++ standardization process and so the reviewers would need to recognize intent to standardize the proposed libraries. Submissions that are supported with a paper in a mailing or a draft will make it easier to source a review manager from this queue, but authors without either are encouraged to get in contact with reviewers on this list to find out what that entails. This is the list of volunteers: Zach Laine Micheal Caisse Matt Calabrese Louis Dionne Vinnie Falco Glen Fernandes Jeff Garland David Sankel The list will rotate; the first person on the list will be "on-call". If you'd like to help, let me know and I'll add your name to the list. Also, I've made a PR that adds this list and a note like the description above to https://www.boost.org/development/submissions.html (#6 Seek a Review Manager): https://github.com/boostorg/website/pull/387 Zach

2 2

[release] Boost 1.69.0 Beta 1 Release Candidate 1
by Marshall Clow 19 Nov '18

19 Nov '18

The release candidates for the first 1.69.0 beta release are now available at: <https://dl.bintray.com/boostorg/beta/1.69.0.beta.1.rc1/source/> The release notes are not yet available. The updated documentation is not yet available. [ They will be available in a day or two. ] The SHA256 checksums are as follows: db6b346389714647490d6503db881e4178dd8cd498f850999bebf72cacd4c4ed boost_1_69_0_b1_rc1.7z d128c82351becbd37a02b9b4818994d3f66ff8bdbc0a18838206f4c070db97af boost_1_69_0_b1_rc1.tar.bz2 4df6262db53cfd0d0f934cb126f7e48e94872fe4441cbac6bf72a43bfb136a45 boost_1_69_0_b1_rc1.tar.gz e2908e33cc15f92cda06ddde6a3da43b18967a83105355571fc3cf6e75820c7f boost_1_69_0_b1_rc1.zip As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Boost Release Managers

6 17

[release] Boost 1.69.0 Beta 1
by Marshall Clow 19 Nov '18

19 Nov '18

Boost release 1.69.0 beta 1 is now available at: <https://dl.bintray.com/boostorg/beta/1.69.0.beta1/source/> The SHA256 checksums are as follows: ee0ecd7d31f58474c1e0210089c9e66bd878d4d1e7436ac511e359aa4a9d3e86 ./boost_1_69_0_b1.7z 3e25c46f2171799caabbeb419ba7859fffb62208f3a1c80798713377ab07af0e ./boost_1_69_0_b1.tar.bz2 71f4b57175058af1b8c320971cf29226e5a652931a679f7e1c086655147ecafb ./boost_1_69_0_b1.tar.gz ec9ef7d2c9f0d41f560769e67bc7ff207cc999243a7dd6c3f6bcfbdbf0827a7b ./boost_1_69_0_b1.zip For details of what's in the release, see < https://www.boost.org/users/history/version_1_69_0.html>. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

1 0

`b2 toolset=clang-win` now works on Appveyor
by Peter Dimov 18 Nov '18

18 Nov '18

With the current develop branch (since Boost.Build hasn't been merged to master yet), b2 toolset=clang-win now works on Appveyor without additional configuration. You can see it in action at https://ci.appveyor.com/project/pdimov/assert/builds/20331077/job/0hux9a6ml…

4 16

[release] Boost 1.69.0 Beta 1 Release Candidate 2
by Marshall Clow 18 Nov '18

18 Nov '18

The release candidates for the second 1.69.0 beta release are now available at: <https://dl.bintray.com/boostorg/beta/1.69.0.beta1.rc2/source/> The release notes are not yet final. The SHA256 checksums are as follows: 77827b25121159a4e65cfbdf19713e2d589fce267fd6f08615a453d24753c9d3 ./boost_1_69_0_b1_rc2.7z ea05c6e01c856369afdab1f6c075e06fb0f965ab1c247f753ed5c951a9db4e71 ./boost_1_69_0_b1_rc2.tar.bz2 b393a73cf084be716c40ef346cfacb1c95e7b14637e8385eeeb50774dd0b99ed ./boost_1_69_0_b1_rc2.tar.gz 74c0c0a19a700fee2b4f434bb7df50840642e3c35924e85864b278bd519af062 ./boost_1_69_0_b1_rc2.zip As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Boost Release Managers

9 29

Re: [boost] [bjam] [build] Documentation for 1.69
by Rene Rivera 17 Nov '18

17 Nov '18

On Fri, Nov 16, 2018 at 1:54 PM Edward Diener <eldiener(a)tropicsoft.com> wrote: > On 11/16/2018 2:40 PM, Rene Rivera wrote: > > On Fri, Nov 16, 2018 at 1:27 PM Edward Diener via Boost < > boost(a)lists.boost.org> wrote: > >> >> It is not really a website/webpage issue but a distribution issue. The >> distribution has an index.html, which gives the doc for the >> distribution, and the link in the doc for the Tool Boost.Build never >> actually exists. >> > > This index.html? <https://github.com/boostorg/boost/blob/master/index.html> > Or some other one? > > In our distribution the top-level index.html brings up the doc. In the doc > there is a link to tools/build/index.html but this html file never exists > in a Boost distribution. Check out any of the past distributions, such as > Boost 1.68, and you will see this. > This <https://github.com/boostorg/boost/pull/218> should fix it. But We'll have to wait until the master branch is open again before it makes it to the release. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

1 0

[release] Boost 1.69.0 Beta 1 Release Candidate 3
by Marshall Clow 17 Nov '18

17 Nov '18

[ Ok, I've rebuilt the RC - and it contains only the changes to function and MPL ] The release candidates for the third 1.69.0 beta release are now available at: <https://dl.bintray.com/boostorg/beta/1.69.0.beta1.rc3/source/> The release notes are not yet final. The SHA256 checksums are as follows: ee0ecd7d31f58474c1e0210089c9e66bd878d4d1e7436ac511e359aa4a9d3e86 ./boost_1_69_0_b1_rc3.7z 3e25c46f2171799caabbeb419ba7859fffb62208f3a1c80798713377ab07af0e ./boost_1_69_0_b1_rc3.tar.bz2 71f4b57175058af1b8c320971cf29226e5a652931a679f7e1c086655147ecafb ./boost_1_69_0_b1_rc3.tar.gz ec9ef7d2c9f0d41f560769e67bc7ff207cc999243a7dd6c3f6bcfbdbf0827a7b ./boost_1_69_0_b1_rc3.zip As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Boost Release Managers

1 1

[spirit] Request to update the master branch with minor doc changes
by Nikita Kniazev 16 Nov '18

16 Nov '18

Do I have a chance to cherry-pick minor doc changes into the upcoming release? I forgot to update version numbers in docs https://github.com/boostorg/spirit/commit/b4f5833cc69f510d3842ba226d8878bb4…

2 1

[build] targeting different versions of libstdc++
by James E. King III 16 Nov '18

16 Nov '18

If I make a system with libstdc++6-dev, libstdc++7-dev, and libstdc++8-dev on it, is there a way to tell clang to use one over the other? By default it will use the latest one. I know that for linking one can use the clang flag "--gcc-toolchain=/usr/lib/gcc/x86_64-linux-gnu/7" to get the link to point at it, but I'm not sure if this also handles the header paths or not. If this option works for both header inclusion and for linking, would I need to specify it as <cxxflags> and also as <linkflags>? Thanks, Jim

2 1

[bjam] [build] Documentation for 1.69
by Cromwell Enage 16 Nov '18

16 Nov '18

Hi, everyone! Will the documentation for Boost.BJam and Boost.Build be included in the release of Boost 1.69? Cromwell D. Enage

5 7

Announcing LEAF, a new error handling library suitable for low latency applications
by Emil Dotchevski 15 Nov '18

15 Nov '18

LEAF (Low-latency Error Augmentation Framework) is a new error handling library which could possibly become the successor of Boost Exception, though LEAF can be used without exceptions too. Official documentation: https://zajo.github.io/leaf/ Features: - No dynamic memory allocations. - Associate objects of arbitrary types with any failure -- when it is initially reported or at a later time. - Compatible with std::error_code, errno and any other error handling API. - Use with or without exception handling. - Support for multi-thread programming. Emil

4 9

Re: [boost] [Boost-users] [release] Boost 1.69.0 Beta 1 Release Candidate 1
by Marshall Clow 14 Nov '18

14 Nov '18

On Mon, Nov 12, 2018 at 4:30 PM Tom Kent via Boost-users < boost-users(a)lists.boost.org> wrote: > > On Mon, Nov 12, 2018 at 9:36 AM Marshall Clow via Boost-users < > boost-users(a)lists.boost.org> wrote: > >> The release candidates for the first 1.69.0 beta release are now >> available at: >> >> <https://dl.bintray.com/boostorg/beta/1.69.0.beta.1.rc1/source/> >> > As always, the release managers would appreciate it if you download >> the candidate of your choice and give building it a try. Please report >> both success and failure, and anything else that is noteworthy. >> > > toolset arch compile Link Execute > msvc-8.0 32 FAIL X X > msvc-8.0 64 FAIL X X > msvc-9.0 32 X X X > msvc-9.0 64 X X X > msvc-10.0 32 X X X > msvc-10.0 64 X X X > msvc-11.0 32 X X X > msvc-11.0 64 X X X > msvc-12.0 32 X X X > msvc-12.0 64 X X X > msvc-14.0 32 FAIL X X > msvc-14.0 64 FAIL X X > msvc-14.1 32 X X X > msvc-14.1 64 X X X > > Compile means that the b2 command completed without errors > Link means that visual studio was able to link a sample executable to a > library (libboost_thread-vcXXX-mt[-gd]-1_XX.lib) > generated > Execute means that the linked program executed without errors. > > Full build logs can be found here: > https://gist.github.com/teeks99/526cf2598d1697557e45e590ce9517be > > Lots of errors with msvc-8.0: > > compile-c-c++ > bin.v2\libs\log\build\msvc-8.0\release\link-static\threadapi-win32\threading-multi\trivial.obj > trivial.cpp > .\boost/parameter/aux_/arg_list.hpp(227) : error C2064: term does not > evaluate to a function taking 1 arguments > .\boost/parameter/aux_/arg_list.hpp(390) : see reference to class > template instantiation 'boost::parameter::aux::arg_list<TaggedArg,Next>' > being compiled > > If there is an easy way to fix arg_list.hpp that would be nice, but if > this is the time to stop build 8.0, that's fine too. > > Also numerous errors for many (all dlls?) of the libraries with msvc-14.0. > They all look something like this: > > > msvc.link.dll > bin.v2\libs\atomic\build\msvc-14.0\release\threading-multi\boost_atomic-vc140-mt-x32-1_69.dll > Creating library > bin.v2\libs\atomic\build\msvc-14.0\release\threading-multi\boost_atomic-vc140-mt-x32-1_69.lib > and object > bin.v2\libs\atomic\build\msvc-14.0\release\threading-multi\boost_atomic-vc140-mt-x32-1_69.exp > msvc.link.dll > bin.v2\libs\system\build\msvc-14.0\release\threading-multi\boost_system-vc140-mt-x32-1_69.dll > Creating library > bin.v2\libs\system\build\msvc-14.0\release\threading-multi\boost_system-vc140-mt-x32-1_69.lib > and object > bin.v2\libs\system\build\msvc-14.0\release\threading-multi\boost_system-vc140-mt-x32-1_69.exp > msvc.link.dll > bin.v2\libs\container\build\msvc-14.0\release\threading-multi\boost_container-vc140-mt-x32-1_69.dll > Creating library > bin.v2\libs\container\build\msvc-14.0\release\threading-multi\boost_container-vc140-mt-x32-1_69.lib > and object > bin.v2\libs\container\build\msvc-14.0\release\threading-multi\boost_container-vc140-mt-x32-1_69.exp > msvc.manifest.dll > bin.v2\libs\atomic\build\msvc-14.0\release\threading-multi\boost_atomic-vc140-mt-x32-1_69.dll > 'mt' is not recognized as an internal or external command, > operable program or batch file. > > if exist > "bin.v2\libs\atomic\build\msvc-14.0\release\threading-multi\boost_atomic-vc140-mt-x32-1_69.dll.manifest" > ( > call "bin.v2\standalone\msvc\msvc-14.0\msvc-setup.bat" x86 >nul > mt -nologo -manifest > "bin.v2\libs\atomic\build\msvc-14.0\release\threading-multi\boost_atomic-vc140-mt-x32-1_69.dll.manifest" > "-outputresource:bin.v2\libs\atomic\build\msvc-14.0\release\threading-multi\boost_atomic-vc140-mt-x32-1_69.dll;2" > ) > > ...failed msvc.manifest.dll > bin.v2\libs\atomic\build\msvc-14.0\release\threading-multi\boost_atomic-vc140-mt-x32-1_69.dll > bin.v2\libs\atomic\build\msvc-14.0\release\threading-multi\boost_atomic-vc140-mt-x32-1_69.lib... > ...removing > bin.v2\libs\atomic\build\msvc-14.0\release\threading-multi\boost_atomic-vc140-mt-x32-1_69.dll > ...removing > bin.v2\libs\atomic\build\msvc-14.0\release\threading-multi\boost_atomic-vc140-mt-x32-1_69.lib > > I'm on the fence if we should continue supporting 8.0, so if that doesn't > get fixed then no big deal. However the issue with (the build tool?) for > 14.0 seems like a showstopper for this RC. > > Do we have any idea why MSVC 14 is failing? -- Marshall (who has been distracted by WG21 stuff)

4 4

What part of "The master branch is closed except by explicit permission" is confusing?
by Marshall Clow 14 Nov '18

14 Nov '18

That means "DO NOT COMMIT TO THE MASTER BRANCH" FULL STOP. I just turned on the auto-updating for the release, expecting two changes: * one from MPL * one from Function. Instead, I got updated from: * Update mpl from master * Update function from master * Update atomic from master * Update log from master * Update convert from master * Update iostreams from master You're making the release process harder. -- Marshall

3 2

Re: [boost] [Boost-users] [release] Boost 1.69.0 Beta 1 Release Candidate 1
by Marshall Clow 14 Nov '18

14 Nov '18

On Wed, Nov 14, 2018 at 9:02 AM Edward Diener via Boost-users < boost-users(a)lists.boost.org> wrote: > On 11/14/2018 11:06 AM, Marshall Clow via Boost-users wrote: > > On Mon, Nov 12, 2018 at 4:30 PM Tom Kent via Boost-users > > <boost-users(a)lists.boost.org <mailto:boost-users@lists.boost.org>> > wrote: > > > > > > On Mon, Nov 12, 2018 at 9:36 AM Marshall Clow via Boost-users > > <boost-users(a)lists.boost.org <mailto:boost-users@lists.boost.org>> > > wrote: > > > > The release candidates for the first 1.69.0 beta release are now > > available at: > > > > <https://dl.bintray.com/boostorg/beta/1.69.0.beta.1.rc1/source/> > > > > As always, the release managers would appreciate it if you > download > > the candidate of your choice and give building it a try. Please > > report > > both success and failure, and anything else that is noteworthy. > > > > > > toolset arch compile Link Execute > > msvc-8.0 32 FAIL X X > > msvc-8.0 64 FAIL X X > > msvc-9.0 32 X X X > > msvc-9.0 64 X X X > > msvc-10.0 32 X X X > > msvc-10.0 64 X X X > > msvc-11.0 32 X X X > > msvc-11.0 64 X X X > > msvc-12.0 32 X X X > > msvc-12.0 64 X X X > > msvc-14.0 32 FAIL X X > > msvc-14.0 64 FAIL X X > > msvc-14.1 32 X X X > > msvc-14.1 64 X X X > > > > Compile means that the b2 command completed without errors > > Link means that visual studio was able to link a sample executable > > to a library (libboost_thread-vcXXX-mt[-gd]-1_XX.lib) > > generated > > Execute means that the linked program executed without errors. > > > > Full build logs can be found here: > > https://gist.github.com/teeks99/526cf2598d1697557e45e590ce9517be > > > > Lots of errors with msvc-8.0: > > > > compile-c-c++ > > > bin.v2\libs\log\build\msvc-8.0\release\link-static\threadapi-win32\threading-multi\trivial.obj > > trivial.cpp > > .\boost/parameter/aux_/arg_list.hpp(227) : error C2064: term does > > not evaluate to a function taking 1 arguments > > .\boost/parameter/aux_/arg_list.hpp(390) : see reference to > > class template instantiation > > 'boost::parameter::aux::arg_list<TaggedArg,Next>' being compiled > > > > If there is an easy way to fix arg_list.hpp that would be nice, > > but if this is the time to stop build 8.0, that's fine too. > > I have essentially backed out a fix on 'develop' for VC++8.0 which > intended to fix another problem with a multiple definitions linking > error, https://github.com/boostorg/mpl/pull/36. > > I would like to push this change to 'master'. It should fix your problem > above with VC++8.0. I will subsequently take another look at the > original fix and see if it can not be corrected. > If you're confident that this will fix the problem, then please do so. -- Marshall

1 0

Re: [boost] [Boost-users] [release] Boost 1.69.0 Beta 1 Release Candidate 1
by Marshall Clow 14 Nov '18

14 Nov '18

On Wed, Nov 14, 2018 at 8:35 AM Edward Diener via Boost-users < boost-users(a)lists.boost.org> wrote: > On 11/14/2018 11:06 AM, Marshall Clow via Boost-users wrote: > > On Mon, Nov 12, 2018 at 4:30 PM Tom Kent via Boost-users > > <boost-users(a)lists.boost.org <mailto:boost-users@lists.boost.org>> > wrote: > > > > toolset arch compile Link Execute > > msvc-8.0 32 FAIL X X > > msvc-8.0 64 FAIL X X > > msvc-9.0 32 X X X > > msvc-9.0 64 X X X > > msvc-10.0 32 X X X > > msvc-10.0 64 X X X > > msvc-11.0 32 X X X > > msvc-11.0 64 X X X > > msvc-12.0 32 X X X > > msvc-12.0 64 X X X > > msvc-14.0 32 FAIL X X > > msvc-14.0 64 FAIL X X > > msvc-14.1 32 X X X > > msvc-14.1 64 X X X > [snip] > Lots of errors with msvc-8.0: > [snip] > This is a result of a change in MPL for VC++8. I will back out this change. > Appreciated. Please test locally, and we'll watch the bots. (Looks like we have two MSVC-8 bots) -- Marshall

1 0

What is status of Boost.Sync?
by Mateusz Loskot 13 Nov '18

13 Nov '18

Hi, The library docs docs say it's been in Boost since 1.55. Boost master has no submodule for it. Boost develop has submodule for it If Sync was removed, why it is still in develop? If Sync was added, hence it is in develop, why the docs mention 1.55 and why it is not in master? What is the status of this thing? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 2

Boost Test Matrix - no clang release builds?
by James E. King III 12 Nov '18

12 Nov '18

I was putting together some additional testing for a library and my CI jobs were failing in release mode. I was able to reproduce the issue locally. On examination of the boost test matrix however I was unable to see the same failures. When I dug into it a little bit more, it looks like the clang linux build jobs only build the default variant (debug), and therefore will not catch release-mode optimization issues when running the unit tests. Here's one of the job details: https://www.boost.org/development/tests/develop/teeks99-02-dc6-17-Docker-64… Given this matrix is the last line of defense before code is merged from develop to master, I'd suggest that the build jobs should all be targeting variant=release instead of variant=debug. The former directly impacts a release, and the latter does not. - Jim

4 3

[hash] Missing boost::hash_value for std::forward_list
by Alexander Zaitsev 11 Nov '18

11 Nov '18

Hello. Recently I found that boost::hash_value has no overload for std::forward_list. Who can tell me - why? Is there any reason and/or limitation? Thank you. -- Best regards, Alexander Zaitsev

1 0

[config] std::uncaught_exceptions
by Lorenzo Caminiti 11 Nov '18

11 Nov '18

Hello all, std::uncaught_exception (singular) is deprecated in C++17 and will be removed in C++20. std::std::uncaught_exceptions (plural) should be used instead. Will Boost.Config have a macro to detect if std::uncaught_exceptions is supported or not by the current compiler? (For example, Boost.Contract implementation uses std::uncaught_exception and it will need to use std::uncaught_exceptions on C++20 compilers instead.) Thanks. --Lorenzo

2 3

[release] 1.69.0 closed for Beta
by Marshall Clow 10 Nov '18

10 Nov '18

The master branch is now closed for all changes except by permission for the Beta release. Also, remember to add your libraries' changes to the release notes at: < https://github.com/boostorg/website/blob/master/feed/history/boost_1_69_0.q… > You can preview the release notes at: <http://www.boost.org/users/history/in_progress.html> Thanks, -- The Boost Release Team

1 0

[release] many release notes pending
by Joaquin M López Muñoz 09 Nov '18

09 Nov '18

Just a heads up about the existence of many umerged lib-specific release notes at: https://github.com/boostorg/website/pulls I seem to remember this same issue happened in 1.68. Maybe some other protocol is needed for handling release notes. Best Joaquín M López Muñoz

6 10

Suggestions for TMP/function introspection problem?
by Hans Dembinski 09 Nov '18

09 Nov '18

Hi all, I am trying to figure out how to solve an introspection problem since a few days, and I am not making progress. I could use some help, it is for boost.histogram. Maybe what I want is not possible... Here is my problem. I have some classes A, B, ... which have some overloaded methods, let's call them `foo`. struct A { void foo(int, char); void foo(bool, int, char); }; struct B { void foo(double); void foo(bool, double); }; I need a way to detect how many arguments the shorter methods has. If the shorter method is foo(Ts...), the longer method is always (bool, Ts...). This is guaranteed. I do not know what Ts... is, it can be anything. I cannot use boost::callable_traits, because an overloaded member function cannot be fetched by name using t = boost::callable_traits::args_t<decltype(&A::foo)>; // fails, overload is ambiguous Can't I match the member function with a template of the form something(bool, Ts...) somehow? Any ideas? Best regards, Hans

2 4

Re: [boost] Boost.Build check to see if cxxflags flag is supported?
by Peter Dimov 09 Nov '18

09 Nov '18

> Note 4: > > This should probably be a feature, like <position-independent>on, which > toolsets translate to -fPIC as appropriate. ... which will fix the case where a shared library uses a static library, but -fPIC is not applied to the static library.

3 3

clang-win, (Thin)LTO this time
by degski 08 Nov '18

08 Nov '18

Starting new thread. Substantial progress has been made towards the goal of compiling Boost with Clang/LLVM (clang-cl.exe, targeting MSVC). The latest PR in this respect by Peter has achieved this. The next step is to be also able to use lld (lld-link in case of clang-cl.exe targeting MSVC) to generate the Boost-libs (static/dynamic). The main interest, IMO, is to be able to use LTO (Thin or Full), which is not possible without the use of LLD. A secondary benefit appears to be faster link times (info from the lld manual). In order to build static ThinLTO-enabled libs, it suffices to pass <compileflags>-flto=thin in the project jam file. The archiving, though, needs to be done with lld-link.exe, passing /lib as the first option (this way it will act as lib.exe, while being able to handle the llvm-byte-code [lib.exe finds the so generated .obj-files to be corrupt]). At consumption time of the libs, lld-link needs to be used for linking. Hacking clang-win.jam:156 to: toolset.flags clang-win.archive .LD $(cond) : "\"C:\\Program Files\\LLVM\\bin\\lld-link.exe\"" /lib ; achieves this goal. I would like to ask (probably Peter) to have a look into whether this can be achieved "the proper way", i.e. to programmatically set that particular line to the required value for this use-case. degski -- *“If something cannot go on forever, it will stop" - Herbert Stein*

4 13

Boost.Build check to see if cxxflags flag is supported?
by James E. King III 07 Nov '18

07 Nov '18

I'm looking for an example for how I could check to see if "-fPIC" is supported for the compiler as part of project requirements. In some recent PRs that include building a static library which then gets included in a shared library, code needs to be built with "-fPIC" on supported platforms/toolsets. There is some code in gcc.jam to do this if the overall link mode is shared (note: this code is not in clang.jam!), but in this case the overall link mode is static, and a Jamfile wraps the result in a shared library, so the directives in gcc.jam are not applied. So at the top level Jamfile, I want to add a project requirement that basically says, "if the compiler supports <cxxflags>-fPIC then use it". Thanks, Jim

3 2

Deadline for 1.69.0 beta extended
by Marshall Clow 07 Nov '18

07 Nov '18

The deadline for closing the master branch for the 1.69.0 beta has been extended until Friday, November 9th. The final release date has not been changed. -- Marshall (who is at a WG21 meeting all week)

1 0

[release][predef] Permission to merge to master..
by Rene Rivera 07 Nov '18

07 Nov '18

I have a change that adds some missing version information for Cygwin OS detection < https://github.com/boostorg/predef/commit/62a50d3892789076272b771f560a419b9…>. Can I merge that to master? -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

2 1

"peer reviewed" - Rights and responsibilities of maintainers
by Alexander Grund 07 Nov '18

07 Nov '18

I'm having trouble with a maintainer of a boost library over a PR and am seeking for clarification. Background (may be skipped): A bug was introduced into the library which I noticed in one of "my" (company) projects leading to a reproducible crash. However the scenario is not that common (although others have the same problem) so it wasn't noticed earlier. I analyzed the problem and created a minimum working example to reproduce this and then opened a PR with a fix. The maintainer did not comment on this for multiple months so given it IS complicated, I factored out additional PRs with tests I created to show the problem, so each PR is fairly small. In the result there were PRs with tests that failed on travis and the fix-PR which included the test-PRs and the fix and succeeded on travis (and all other CIs) and users reported success using this PR. Still no response from the maintainer on any PR. He then added an own test claiming to be enough, while I (as the author of the original tests) knew it wasn't as e.g. it didn't fail. (so what's it worth then?) Furthermore he added a commit changing unrelated stuff and ADDITIONALLY changing code I touched in the fix claiming that it would be the essence of my patch and fix the problems. Again I (as the author of the original patch) know that this is not true especially as the test-PRs still fail with his patch applied. So my point/problem is: Is the maintainer allowed to simply do changes as he wishes without any review at all? My expected procedure is: - Someone creates a PR - Maintainer (and optionally the community) reviews (and comments on) it - It eventually gets merged or rejected with comments why OR: - Someones else (including the maintainer) creates a contra-PR fixing the same problem - That author explains, how and why this fixes the same problem and why it is superior to the original PR - This gets reviewed and either PR gets merged Arguments were made, that this doesn't apply to accepted boost libraries as e.g. "it's [the maintainers] heads that got chopped off if something gets broken". I would challenge this by the simple example at hand: This boost library IS broken and it crashes MY application (and others). But I see no heads rolling. Furthermore: If the maintainer is allowed to patch and change as he wants without ANY review, how can Boost still be called "peer reviewed"? My trust in Boost stems from the extensive review a library has to undergo before it is included in Boost. If afterwards no review is happening or reviews are actively avoided (as in the current example), then the older a Boost library gets, the less trust I would have in it as more and more unreviewed changes get included. So again: What is the Boost course on reviews of existing libraries and the statement on the rights and responsibilities of maintainers? Thanks, Alexander Grund

15 52

[parameter] Go C++11 and above only, or keep C++03 support?
by Cromwell Enage 06 Nov '18

06 Nov '18

Hi, everyone. The end of section 3.2.1 of the current Boost.Parameter home page tutorial notes "that because of the forwarding problem, parameter::parameters::operator() can't accept non-const rvalues". I've submitted a PR to the develop branch on GitHub that would grant Boost.Parameter the ability to support perfect forwarding and eliminate this issue. However, the PR uses rvalue references (in parameter::keyword, parameter::parameters, and the code generation macros) and variadic templates (in parameter::parameters and the code generation macros). With the exception of BOOST_PARAMETER_TEMPLATE_KEYWORD, the PR would make Boost.Parameter a C++11 library. As a result--based on < http://pdimov.github.io/boostdep-report/develop/parameter.html#reverse-depe…>--the following Boost libraries known to use Boost.Parameter would also become C++11: Boost.Accumulators Boost.Convert Boost.Graph Boost.Heap Boost.Log Boost.MetaStateMachine or Boost.MSM Boost.Parameter_Python Boost.Signals2 I'd like to hear from everyone else, especially the maintainers and users of these libraries, if it's okay for Boost.Parameter to go C++11 and above only or if C++03 support is still necessary. Cromwell D. Enage

14 37

[testing] Lots of spurious test runners
by John Maddock 05 Nov '18

05 Nov '18

There are rather a lot of test runners that fail all tests due to setup errors: sandia-gcc-5.4.0-c++11 cc1plus: error: unrecognized command line option "-std=c++11" sandia-gcc-5.4.0-c++14 cc1plus: error: unrecognized command line option "-std=c++14" sandia-gcc-6.4.0-c++11 cc1plus: error: unrecognized command line option "-std=c++11" sandia-gcc-6.4.0-c++14 cc1plus: error: unrecognized command line option "-std=c++14" sandia-intel-16.0-c++11 /bin/sh: line 1: icpc: command not found sandia-intel-16.0-c++14 /bin/sh: line 1: icpc: command not found sandia-intel-16.0 /bin/sh: line 1: icpc: command not found sandia-intel-17.0-c++11 /bin/sh: line 1: icpc: command not found sandia-intel-17.0-c++14 /bin/sh: line 1: icpc: command not found sandia-intel-17.0 /bin/sh: line 1: icpc: command not found teeks99-02-dc3.1-11-Docker-64on64 /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/functional:2194:2: error: no type named 'type' in 'std::enable_if<false, void>' (and more errors from <functional> - the compiler appears to be unable to handle the std lib headers so I'm not sure what the point of testing it is?) igaztanaga-develop-gcc-3.4c++03 cc1plus.exe: error: unrecognized command line option "-fvisibility-inlines-hidden" cc1plus.exe: error: unrecognized command line option "-fvisibility=hidden" Best, John. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

4 3

interest in a flag library
by Masse Nicolas 05 Nov '18

05 Nov '18

Hi all, This is the first time I post on this mailing list :). I'm posting because i'd like to know if people would be interested in a library to treat enum types as flags. I find that's something which is lacking in the language since the introduction of strongly typed enums, and I've since written some code in order to do this. So far I've seen some discussion on this mailing list about that, but it doesn't seems that any library have been written yet. So do you think it is worth the effort of porting and documenting my code so that it can integrated into boost, or not? Regards, Masse Nicolas. PS: For those interested, the code consists of a flag class, and overloads operators like '|' or &. It can be used like this: enum struct option : uint { none = 0, first = 1, second = 2, third = 4, forth = 8 }; static constexpr flags<option> var1 = option::first; static constexpr flags<option> var2 = option::second | option::third; static constexpr auto var3 = var1 | var2; /* type will be resolved into flags<option> */ static constexpr auto var4 = option::first | option::second | option::third; /* works too */ int main() { std::cout << var1 << std::endl; std::cout << static_cast<uint>(var2) << std::endl; /* note that static_cast<int> won't compile since the underlying type is uint */ std::cout << (var3 & option::forth) << std::endl; std::cout << (var3 == var4) << std::endl; return 0; }

8 9

Boost.CI for Boost Repository Build Quality
by James E. King III 05 Nov '18

05 Nov '18

Continuous Integration is a modern cornerstone of delivering quality results in software engineering. When I started getting involved in boost as a maintainer (instead of a long-time consumer) it became a goal to get CI into as many repositories as possible. CI allows submitters to self-check their code changes without bothering the maintainer(s) of each repository. It eases the burden for maintainers as they can focus more on code review, and less on manual machinations to validate changes (by running code locally in their own environments). The wide coverage of builds in Boost.CI has helped identify a number of issues and improved the quality of those repositories. Performing these tests and analyses before code is merged catches issues earlier (but is not as comprehensive as the test matrix in terms of platform support due to limitations in the CI providers). Given that the Travis CI and AppVeyor builds for almost all the CMT repositories (and a few others) are using Boost.CI, it's proper place is under the "boostorg/" GitHub organization. Right now it's under my GitHub account, but I would like to move it to a more official location. https://github.com/jeking3/boost-ci Thanks, Jim

3 4

Draft copy - Call for Submissions - CMake for Boost
by Robert Ramey 05 Nov '18

05 Nov '18

The following is a draft of the document of I have planned to post on behalf of Boost on or around 1 November 2018 as the first step in our next attempt to accommodate CMake in Boost. Robert Ramey Call for Submissions - CMake for Boost ====================================== For some time, there has been interest on many users and developers of Boost Libraries to make Boost easier to use with CMake. Discussions in the past have not resulted in an implementation which has been widely accepted. Never the less, hope springs eternal, and we intend to attempt this once again. It seems that often there are difficulties before such projects even start in that there are wide discrepancies as to what should be the goals and expectations of Boost support of CMake. The aim of this document is to try to build a consensus on this question before encouraging CMake developers and experts to submit proposals for Boost support of CMake. Requirements and Scope ====================== Requirements ------------ Submissions will fulfill the applicable requirements of any boost submission. This will include: a) any necessary code. b) specifications/requirements for things like directory structure and contents. b) A useful document. Document should provide information, examples and templates so that a typical C++ and CMake user should be able to do any of the following in a short time - say 10 minutes. Document at a minimum should be viewable as html and/or PDF file. 1) A library user should be able to incorporate a Boost Library into the CMake script. 2) A library user should be able to determine which additional Boost Libraries he needs. 3) A library developer should find it simple to create the requisite CMake files for his library. Thus the documentation should contain explanation and perhaps other means such as examples and/or "templates" for required CMake files. c) test of CMake facilities supported by the CMake implementation. This will include code, test of any features, capabilities that the submission provides. Users expect that if they follow the instructions in the documentation, they will get the promised results. A manner of proving this must be provided. A likely response to this requirement would be a "test project" which can be used to demonstrate that the submission actually works. This will be useful in the future for maintenance of the CMake Boost implementation. It will permit the maintainer of the Boost.CMake facility to work on and test their fixes and improvements without disrupting other developers and users. d) a Boost License Facilities and features ----------------------- CMake as it stands has lots of capabilities. But it has a fair amount of complexity as well. Lots of things can be accomplished in multiple different ways - each with subtly different results and effects. CMake for Boost will likely consist of documentation, examples, CMake code, and other stuff to use CMake to permit new features and facilities for users and developers of Boost libraries. What follows is a list of facilities that Boost users and developers would like to acquire with CMake for Boost. Those marked with * should be considered hard requirements. That is, submissions which don't include this feature can't be considered. Other items are interesting and would be considered if included in a submission. *a) incorporating selected Boost Libraries into a user's application *b) incorporating selected Boost Libraries into a user's library c) building a boost library d) building a boost tool such as Boost.bcp, Boost.boostdep, etc. e) testing a boost library - if testing of Boost libraries is to be supported, the following features should be considered. Those marked * should be considered essential. *1) execution tests - must pass/ must fail *2) compile only tests - must pass/ must fail *3) link only tests - must pass/ must fail 4) should be available to both users and developers 5) should not depend upon tools other than C++. 6) test should have the option of posting the results to some public "dashboard" 7) option for recursive testing and/or building of libraries might be nice. That is if library A uses library B and I test library A, this would automatically test library B beforehand. *f) In CMake, dependent libraries are specified as part of the library CMakeLists.txt files. There several ways to do this and the subject is pretty confusing to get right. Any submission documentation has to explain to library developers how do this. g) Some have suggested a highly automated process including downloading/updating, finding other components on other machines, etc. This shouldn't be considered h) packaging - preparation of distributable, installable files for various operating systems. That is support for the CPack facility. i) There has been a lot interest and work in automatically determining dependencies It's a much deeper subject than most people realize. Solving this problem is not a requirement of the submission. However, submitters are free to address this if they desire. *j) support of library modularity. This would mean: *1) independence of things outside the library directory structure. To wit - no presumption about any "super project". *2) building out of tree *3) no need for installing libraries not used by the build target k) ... Submission Rules and Procedures ------------------------------- a) This document constitutes a "Request for Submissions". It will be announced on the boost announcements list, boost developer's list, slack/boost, isocpp website and twitter account, reddit at r/cpp. Submissions will be open to anyone. b) Submissions will be accepted at an email address to be specified. Received submissions will receive a "prescreening" to determine that they meet the requirements specified for such submissions at the top of this document. Those that don't will be returned to the author. c) The name of the author of a submission will not be included in the submission. Authors will be expected to take reasonable efforts to maintain his anonymity via a github repo without a real name assigned, anonymous, email address etc. We understand that the nature of the submission and debate during subsequent review of the proposals. Never the less we believe that anonymity can be mostly maintained. The the true identity of the author of the selected proposal will not be revealed until the selection is made. The motivation for this anonymity is to attract submitters who find the boost review process distressing, annoying and/or unpleasant. It should also address the concerns of those who beleive that by not being a "boost insider" they won't get fair consideration. Boost is first and foremost a meritocracy. We seek the very best in everything regardless of other considerations. d) Submissions will be closed on or about 1 February 2019. Boost formal review will commence shortly there after. Depending on the number of submissions received, the process may last as long as month. e) As per the boost formal review rules and customs, some time after the review period terminates, the review manager will announce the review results. This will likely contain some conditions regarding alterations required in the submissions implementations. I the author find these too onerous, and declines the opportunity to integrate his submission as an official part of boost, the review manager may select an alternate submission. It's also possible that the review manager may decide to accept none of the submissions. f) when the submission is integrated into boost and is shown fulfill the requirements stipulated by the review manager. The author will receive a "prize" of $5000 and a large but cheap medal on a ribbon hopefully to be awarded at the next C++Now (Boost Con). As this is written, this prize is subject to finding a funding source. It's understood that this stipend is in no way compensation, for all the work and aggravation of this task. But we hope that it will serve as a tangible token of our gratitude for solving one of Boosts most pressing and difficult problems. Useful Resources =============== “Effective CMake" - https://www.youtube.com/watch?v=bsXLMQ6WgIk https://gist.github.com/mbinna/c61dbb39bca0e4fb7d1f73b0d66a4fd1 https://github.com/purpleKarrot/Boost.CMake https://steveire.wordpress.com/2016/08/21/boost-dependencies-and-bcp/

10 28

Has anyone thought about adding a general case subset class?
by jrmarsha 04 Nov '18

04 Nov '18

I've got a lot working with my madlib version of graph, but I've been thinking over the elegant ways to add the subgraph feature in BGL. It occurred to me that this can be phrased as a more general problem as container subsets. And while we're at that, then we can add objects or operators for set operations like inner join, left join, and outer join. Can I get some thoughts?

1 0

Fwd: Errors in test matrix
by Stefan Seefeld 03 Nov '18

03 Nov '18

[I haven't received a reply on the boost-testing list, so I'm resending to the general list in the hopes that someone can help.] -------- Forwarded Message -------- Subject: Errors in test matrix Date: Wed, 31 Oct 2018 09:41:05 -0400 From: Stefan Seefeld <stefan(a)seefeld.name> To: Running Boost regression tests <boost-testing(a)lists.boost.org> Hello, [I'm not entirely sure this is the right place for the report. Please let me know if it isn't, and where to post instead.] On https://www.boost.org/development/tests/develop/developer/numeric-ublas.html, I'm looking at failures in the "Sandia" columns. Following one link takes me to https://www.boost.org/development/tests/develop/developer/output/Sandia-gcc…, which demonstrates a couple of issues: * What compiler version is this using ? The URL contains both "5.4.0" as well as "4.4.7". * The actual error reads "unrecognized command line option -std=c++11". Given that Boost.uBLAS itself doesn't specify this flag, I assume it's part of the test runner's configurations. However, it seems to be used with a compiler version that doesn't support it (though again, it isn't clear which compiler version we are actually talking about). Unfortunately there are quite a large number of columns with similarly generic errors, i.e. errors more likely to be caused by invalid set ups, rather than genuine errors in the library (libraries, as I'm seeing similar errors in other libraries). What can I do about this ? Ignore the errors ? It would be good if the metainfo that is displayed with the test runners included a point of contact (mail address ?) to report such errors. Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...

2 1

Re: [boost] [parameter] Go C++11 and above only, or keep C++03 support?
by Nikita Kniazev 03 Nov '18

03 Nov '18

The major problem is that Boost does not see its users; most of them do not read mail lists and changelogs, even documentation is read only during active development and by developers who actually touches boost namespace. To library maintainers they usually appear only when something is completely broken and we cannot blame anyone about it, but it makes nearly impossible to gather any statistics. The other point is that Boost is free and users may decide not to raise their voice because it can look like they try to dictate investment priorities of others spare time. If Boost really wants to survey C++03 users it can be most effectively done in the code by showing them a message with a conditional pragma #error “Boost wants to hear your voice. It is time to revise the minimal requirements. Please give us feedback about your preferences at <url> or mail list. To continue #define BOOST_I_ACKNOWLEDGE_EMERGING_CXX03_DEATH” in some libraries or globally in Boost.Config headers. It is not too late to make this for 1.69.

2 1

[release] 1.69.0 closed for major changes
by Marshall Clow 01 Nov '18

01 Nov '18

The master branch is now closed for new libraries and breaking changes, and will be closing for the beta in one week. Also, if you're ready, you can also add your libraries' changes to the release notes at: < https://github.com/boostorg/website/blob/master/feed/history/boost_1_69_0.q… > After editing the release notes, you should get a form to create a pull request, remember to submit it, otherwise I won't see your change. Thanks, -- The Boost Release Team

1 0

clang-win, again
by Peter Dimov 31 Oct '18

31 Oct '18

Has anyone succeeded in getting clang-cl.exe working under b2? I've installed llvm-6.0.1, added it to PATH, put using clang-win : : : <compatibility>vc14 ; in my user-config, and what I get is: C:\boost-git\develop\libs\smart_ptr\test>b2 toolset=clang-win sp_interlocked_test warning: mismatched versions of Boost.Build engine and core warning: Boost.Build engine (b2) is 2015.07.00 warning: Boost.Build core (at C:/boost-git/develop/tools/build/src) is 2018.02-git C:/boost-git/develop/tools/build/src/tools\msvc.jam:1087: in set-setup-command *** argument error * rule virtual-target.from-file ( file : file-loc : project ) * called with: ( : /C:/boost-git/develop/libs/smart_ptr/test : object(project-t arget)@129 ) * missing argument file C:/boost-git/develop/tools/build/src/build\virtual-target.jam:970:see definition of rule 'virtual-target.from-file' being called C:/boost-git/develop/tools/build/src/tools\msvc.jam:652: in clang-win.compile.c+ + C:/boost-git/develop/tools/build/src/kernel\modules.jam:107: in modules.call-in C:/boost-git/develop/tools/build/src/util\indirect.jam:105: in indirect.call C:/boost-git/develop/tools/build/src/build\virtual-target.jam:902: in execute C:/boost-git/develop/tools/build/src/build\virtual-target.jam:821: in class@acti on.actualize C:/boost-git/develop/tools/build/src/build\virtual-target.jam:332: in actualize- action C:/boost-git/develop/tools/build/src/build\virtual-target.jam:518: in actualize- no-scanner C:/boost-git/develop/tools/build/src/build\virtual-target.jam:142: in class@virt ual-target.actualize C:/boost-git/develop/tools/build/src/build\configure.jam:258: in try-find-build C:/boost-git/develop/tools/build/src/build\configure.jam:396: in find-builds-raw C:/boost-git/develop/tools/build/src/build\configure.jam:455: in configure.find- builds C:/boost-git/develop\boostcpp.jam:734: in boostcpp.deduce-address-model C:/boost-git/develop/tools/build/src/kernel\modules.jam:107: in modules.call-in C:/boost-git/develop/tools/build/src/util\indirect.jam:105: in indirect.call C:/boost-git/develop/tools/build/src/build\property.jam:144: in property.evaluat e-conditionals-in-context C:/boost-git/develop/tools/build/src/build\targets.jam:1087: in evaluate-require ments C:/boost-git/develop/tools/build/src/build\targets.jam:1121: in common-propertie s2 C:/boost-git/develop/tools/build/src/build\targets.jam:1017: in targets.common-p roperties C:/boost-git/develop/tools/build/src/build\targets.jam:1313: in class@basic-targ et.generate C:/boost-git/develop/tools/build/src/build\targets.jam:812: in generate-really C:/boost-git/develop/tools/build/src/build\targets.jam:784: in class@main-target .generate C:/boost-git/develop/tools/build/src\build-system.jam:797: in load C:\boost-git\develop\tools\build\src/kernel\modules.jam:295: in import C:\boost-git\develop\tools\build\src/kernel/bootstrap.jam:139: in boost-build C:\boost-git\develop\boost-build.jam:17: in module scope

9 74

[property-tree] state of the library, fixes and extensions
by Goehring, Christian 31 Oct '18

31 Oct '18

Hi @all, the property-tree lib seems to be in some sort of dormant state judging from the repository activity. Is this library still actively maintained (for example, the xml-functionality would need some support for CData)? Do you know if there is any need for extensions (for example JSON-support) or did some other alternative succeed this library? Thanks in advance! Best, Christian

1 0

questions regarding visibility and b2
by Robert Ramey 30 Oct '18

30 Oct '18

I've got a few questions about the "visibility" changes for boost. My understanding is that "visibility" for gcc and clang are "sort of the same thing" as dll import and export are for windows. Now we've made "visibility" the "default". But this seems kind of weird. This has been made a b2 feature. In order to run tests, this feature is applied to the b2 command line. What's weird is that it's applied to the tests/executables and propogated down to libraries which are built. I actually don't know what "visibility" means in the context of building and executable. If I want to use visibility=global then on the library build, it needs to be applied to everything. It's very weird and doesn't seem in line with the windows solution. Heretofore, I've applied visibility to the library build "by hand" by adding the appropriate command line switches to the right places. I'm aware that this is not the b2 way. But the b2 way doesn't seem to make sense to me. On the bright side, changing default visibility didn't seem to have any effect on the serialization library other than on one test. Unfortunately, turning this confused a pending issue and made it even more contentious than it already is/was. FWIW - this is not so much the fault of b2 or anyone in particular. The use of DLLS/shared libraries is the triumph of development over design by vendors, each of whom do their own thing and have never been able to get it together. By now this has created enough technical debt that it will take years to straighten out if people actually start to address it, which no one seems interest in doing. Anyway, the b2 approach is pretty confusing and probably wrong. I'm also guessing that, as one would predict, a change like this is going to provoke subtle failures in lots of small corners which will take quite a while to discover. I'm not sure how to address this. Robert Ramey

4 5

[release] 1.69.0 deadline for new libraries approaching
by Marshall Clow 29 Oct '18

29 Oct '18

It's that time again! On Wednesday, the master branch will be closed for adding new libraries. Upcoming dates: * 24-Oct: Boost 1.69.0 closed for new libraries and breaking changes * 31-Oct: Boost 1.69.0 closed for major code changes * 7-Nov: Boost 1.69.0 closed for beta * 14-Nov: Boost 1.69.0 beta 1 * 5-Dec: Boost 1.69.0 closed for release * 12-Dec: Boost 1.69.0 release -- The Boost Release Team

7 10

Is boost supported on z/os
by Naveen Sharma 28 Oct '18

28 Oct '18

Hello Does boost supported on z/os or may be subset of library. We are planning to replace our current library with boost. One of the platform we support is z/os and so I am researching if boost can be compiled and usable on the platform. I did searched on the internet but did not get much information. Before I dive into it, I thought to ask. Thanks Naveen

2 2

Re: [boost] [histogram] Objections against switch to C++14?
by Bjorn Reese 28 Oct '18

28 Oct '18

On 10/22/18 6:42 PM, Hans Dembinski wrote: > Do you object against raising the requirement from C++11 to C++14 for the implementation of boost.histogram? No objection from my side. However, you may consider making parts of the library available to C++11 users, because there are plenty of those out there.

1 0

Builds from boost/status fail early?
by James E. King III 27 Oct '18

27 Oct '18

Using develop from this morning (tried various combinations of these three options...): boost@d48d3305d4b4:/boost/status$ ../b2 toolset=clang variant=release cxxstd=03 ... /boost/tools/build/src/build/feature.jam:491: in validate-value-string from module feature error: "shared:" is not a known value of feature <link> error: legal values: "shared" "static" /boost/tools/build/src/build/feature.jam:365: in expand-subfeatures-aux from module feature /boost/tools/build/src/build/feature.jam:422: in expand-subfeatures from module feature /boost/tools/build/src/build/feature.jam:871: in feature.expand from module feature /boost/tools/build/src/build/targets.jam:1103: in evaluate-requirements from module targets /boost/tools/build/src/build/targets.jam:1121: in common-properties2 from module targets /boost/tools/build/src/build/targets.jam:1017: in targets.common-properties from module targets /boost/tools/build/src/build/targets.jam:1313: in class(a)basic-target.generate from module object(typed-target)@47912 /boost/tools/build/src/build/targets.jam:812: in generate-really from module object(main-target)@70272 /boost/tools/build/src/build/targets.jam:784: in class(a)main-target.generate from module object(main-target)@70272 /boost/tools/build/src/build/targets.jam:273: in class(a)project-target.generate from module object(project-target)@47307 /boost/tools/build/src/build/targets.jam:273: in class(a)project-target.generate from module object(project-target)@4568 /boost/tools/build/src/build-system.jam:797: in load from module build-system /boost/tools/build/src/kernel/modules.jam:295: in import from module modules /boost/tools/build/src/kernel/bootstrap.jam:139: in boost-build from module /boost/boost-build.jam:17: in module scope from module

3 12

[statechart] visibility change broke things
by James E. King III 27 Oct '18

27 Oct '18

Boost.StateChart wasn't building on a regular basis. It looks like the visibility changes broke it. I opened an issue for it. I also changed Travis CI to build it monthly.

1 0

[serialization] boost:array
by Yuval Lifshitz 27 Oct '18

27 Oct '18

Any idea on why was the serializer for boost:array removed?Can we re-introduce it? Yuval Lifshitz

1 0

Fwd: Syntax highlighting for Boost.Jam language in Visual Studio Code
by Mateusz Loskot 27 Oct '18

27 Oct '18

I've announced this on boost-build but I think folks here may find it useful as well. Mat ---------- Forwarded message --------- From: Mateusz Loskot <mateusz(a)loskot.net> Date: Fri, 26 Oct 2018, 23:18 Subject: Syntax highlighting for Boost.Jam language in Visual Studio Code To: <boost-build(a)lists.boost.org> Hi, (A pet project warning!) I've published an extension for VSCode with a brave attempt to color-hightlight syntax of Jam language: https://github.com/mloskot/vscode-boost-jam This is based on a very basic TextMate language grammar definitions, often naive, and, by no means, it is complete or bug-free coverage of the Jam. Even so, I think it quite helps to de-annoy or even enjoy process of writing Jam scrips :-) I'm no expert of writing TextMate language grammars - this is my first ever attempt - so chances are I may be incapable of fixing bugs or improving it with advanced features. Especially, that "the process of writing a TextMate language grammar remains poorly documented" - http://www.apeth.com/nonblog/stories/textmatebundle.html Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

Mailman upgrade
by Brad Johnson 27 Oct '18

27 Oct '18

Happy Late October all. Just a quick notification that mailman upgraded from 2.1.26 -> 2.1.29 at 27-Oct-2018 02:50 UTC. Release notes for 2.1.27, 2.1.28, and 2.1.29: https://launchpad.net/mailman/2.1/2.1.27 https://launchpad.net/mailman/2.1/2.1.28 https://launchpad.net/mailman/2.1/2.1.29 Sanity checks on test mailing list shows mail is still flowing and archiving. Any questions or concerns, please let me know at this address or sysadmin(a)boost.org. Thanks, -- Brad Johnson Ciere Consulting 916.877.6030 brad.johnson(a)ciere.com ciere.com

1 0

[parameter_python] Merge to master
by Edward Diener 26 Oct '18

26 Oct '18

I would like to merge parameter_python to 'master' from 'develop'. Does anybody see anything wrong with this ? This fixes using Python 3+ with parameter as well as Python 2+, among other things.

3 4

Library devs only: Boost v2.x distro design questions
by Niall Douglas 26 Oct '18

26 Oct '18

Splitting this off from the other thread, can I get feedback from Boost library maintainers ONLY. Not users, not non-maintainers. Q0: Are you willing to do the work to adapt your library for any Boost v2.x distro if it were to happen? Q1: Would you prefer a new, separate Boost v2.x distro in parallel to the v1.x distro, or to keep everything within one v1.x distro? Q2: Would you be intending to keep your library inside Boost v1.x, move it exclusively to Boost v2.x, or have it exist in both Boost v1.x and v2.x but with different defaults configured? Also, would the version in v1.x be hard forked from any v2.x edition i.e. the v1.x edition would get orphaned? Q3: What C++ standard should Boost v2.x's master build system be defaulted to? C++ 11, 14, 17 or 20? Q4: Should Boost v2.x use a boost2 namespace, or namespace boost { inline namespace v2 { }}? (This affects whether Boost v2 and v1 editions of your library can be used within the same translation unit) Q5: What master buildsystem should Boost v2.x use? Boost.Build, cmake, Build2, something else? Q6: Should Boost v2.x's libraries auto integrate individually into some package manager? If so, which ones do you intend to support? Q7: Should Boost v2.x have official release versions done by release managers, or should it be a rolling release of "whatever last passed the CI @ 100%"? Note that you can have this, and have official release versions of "especially known good" editions too. Q8: Should Boost v2.x use a local HTML server to serve documentation, and the static HTML docs be dispensed with as a requirement? Q9: What are your feelings towards the use of Python to script infrastructure and tooling in any Boost v2.x? For example, Python to run a local HTML server to serve documentation locally, or Python to build a release etc Q10: What parts of core Boost are you utterly dependent upon, and would absolutely need ported to any Boost v2.x as no STL alternatives exist? I could go on, but let's stop there for now. Niall

12 16

[histogram] Objections against switch to C++14?
by Hans Dembinski 26 Oct '18

26 Oct '18

Dear reviewers of boost.histogram, thank you again for your reviews. I am currently working on the issues raised during the review and some of the requested features would be easier to implement when the library standard is raised from C++11 to C++14. This only affects the implementation side, not the user side. It would make my life easier and the implementation code more readable, because I can emulate `if constexpr` using in-place generic lambdas instead of out-of-place functors in the detail namespace. To make the library more user-friendly, I have to do more and more of these emulated `if constexpr`. Do you object against raising the requirement from C++11 to C++14 for the implementation of boost.histogram? Best regards, Hans

3 3

[smart_ptr] sharable_ptr any interest
by Marc Pawlowsky 26 Oct '18

26 Oct '18

I am working on a idea for a smart pointer called sharable_ptr. A cross between a unique_ptr and a shared_ptr. A sharable pointer has a single definite owner like a unique_ptr, and can be shared to other users similar to shared_ptr as a borrowed_ptr. However unlike a shared_ptr it is an error if the contents of the sharable_ptr go out of scope, by destruction or being reset or assigned, if there are still instances of a borrowed_ptr that reference it. The work is in its infancy at https://github.com/marcpawl/smart_ptr/tree/feature/leased_ptr with the documentation at https://github.com/marcpawl/smart_ptr/blob/feature/leased_ptr/doc/smart_ptr… >From the documentation: Motivation sharable_ptr, and its cohorts: sharable_ref, borrowed_ptr, and borrowed_ref are to help close the raw dangling pointer problem. Along with unique_ptr and shared_ptr, the number of C++ objects that will retain a raw pointer can be reduced. It will allow for easier reasoning of the lifespan of objects, and help catch errors where an object is referenced after it no longer should be. <https://github.com/marcpawl/smart_ptr/blob/feature/leased_ptr/doc/smart_ptr…> Analogy Marc owns a cottage on the lake and is willing to share it with his friends and family. He tells them to drop by anytime they want, even when he is not there. Amanda uses the cottage on a regular basis. Amanda also lets her friend Ava use it. Unfortunately due to a change in financial circumstances Marc has to sell the cottage. At this point neither Marc nor Amanda may use the cottage any more. In C++ terms, Marc has a sharable_ptr<Cottage>. When Amanda is at the cottage she has a borrowed_ptr<Cottage>, which she destroys when she leaves the cottage. When Amanda lets Ava use the cottage Ava gets a copy of the borrowed_ptr. Amanda and Ava must destroy their pointers prior to Marc releasing his. It would be an error for Amanda or Ava to retain a borrowed_ptr to the cottage even if she does not use it. Equivalent to retaining a copy of the keys. ## Alternatives Instead of using `sharable_ptr` and `borrowed_ptr`, you could use `shared_ptr` and `weak_ptr`. The error detection for a dangling pointer gets pushed to when the `weak_ptr` is locked to a `shared_ptr`, instead of when the owned object is freed. A possible advantage is that if the `weak_ptr` is not used then there is no error. The disadvantage is the code may have progressed quite a way before it is realized the referenced object no longer exists. Is there interest in this idea, should I keep working on it? I have so far only been working on Mac clang basement:smart_ptr marcpawl$ clang -v Apple LLVM version 10.0.0 (clang-1000.10.44.2) Target: x86_64-apple-darwin17.7.0 Thread model: posix Thanks Marc Pawlowsky

2 1

interest in a flag library
by Marc Pawlowsky 26 Oct '18

26 Oct '18

You should take a look at https://www.youtube.com/watch?v=1fwbG5TyI18 CPPCON 2018 session https://cppcon2018.sched.com/event/FnKQ/avoiding-disasters-with-strongly-ty… Arno Lepisk <https://cppcon2018.sched.com/speaker/arno_lepisk> Avoiding Disasters with Strongly Typed C++ I think the technique he describes is what you are looking for.

1 0

[c++ question] detecting reference to temporaries
by Raffi Enficiaud 25 Oct '18

25 Oct '18

I have a stupid question related to a bug in boost.test. A piece of code is doing something like: const value& get() { return *internal_iterator; // can be a ref or not to value or another type } The fix is trivial, *but* I want to test it. Is there any technique that would let me test for reference to temporaries? The only option I see would be to promote compiler warnings into error, but maybe there is something there? Thanks, Raffi (complete example here: https://github.com/boostorg/test/blob/90d577a620e008417af79f5caa25e701eef95… )

2 1

[boost.random] Library maintenance
by Nikita Kniazev 25 Oct '18

25 Oct '18

Random library has multiple PRs that hang for a long time already. Some of them address warnings that poisons its usage and maintenance of other libraries. Please consider placing Random under CMT. https://github.com/boostorg/random/pull/35 https://github.com/boostorg/random/pull/26 https://github.com/boostorg/random/pull/31

1 0

Re: [boost] [c++ question] detecting reference to temporaries
by Nikita Kniazev 25 Oct '18

25 Oct '18

> Is there any technique that would let me test for reference to > temporaries? The only option I see would be to promote compiler warnings > into error, but maybe there is something there? AddressSanitizer with -fsanitize-address-use-after-scope https://github.com/google/sanitizers/wiki/AddressSanitizerUseAfterScope

1 0

Boost 2 and build2
by Boris Kolpackov 25 Oct '18

25 Oct '18

I've noticed the discussion on Boost 2 where build2 was mentioned as one of the potential build systems. So I wanted to say that we would be happy to help on our side with any questions, missing features (like exporting targets in a CMake-compatible manner, as mentioned by Niall), etc. Also a couple of additional points about build2 that I think could be relevant to Boost 2 (or 1): 1. It is currently the only build system that I am aware of that has support for C++ modules (currently TS but we are tracking the standardization/implementation progress closely; see [1] for details). Now that modules are likely to be in C++20 I think this should be at least a consideration for Boost 2. 2. We have a public CI service[2] for open source project that I think could be quite useful to Boost. It might not currently be as extensive as Boost's (see [3] for the currently offered build configurations) but we are continuously expanding it plus Boost can run its own build machines with additional configurations. 3. build2 comes with a package manager[4] and Boost could take advantage of that by either publishing to cppget.org or running its own package repository (or both). I am happy to answer any questions here (if appropriate, of course), on the build2 mailing list[5], or on the #build2 slack channel[6]. [1] https://build2.org/build2/doc/build2-build-system-manual.xhtml#cxx-modules [2] https://ci.cppget.org [3] https://ci.cppget.org/?build-configs [4] https://build2.org/build2-toolchain/doc/build2-toolchain-intro.xhtml#guide-… [5] https://lists.build2.org/ [6] https://cpplang.slack.com/app_redirect?channel=build2

1 0

The future and present of Boost
by Robert Ramey 25 Oct '18

25 Oct '18

This was on another thread. Someone mentioned that it should be on it's own thread so here it is (slightly amended for context). For some time I've been concerned about the future of Boost as an organization. Here are the concerns I have: a) With C++11, the standards committee accepted a large portion of Boost into the standard. This left it unclear as to what the future value of Boost to C++ might be. b) The standards committee has ramped up it's efforts to include library proposals directly into the standard - thus side stepping the traditional requirement of "standardizing established practice". So this has left Boost, which helps to evolve "establish practice" outside of the development of the C++. An example of this has been the Ranges library which as been designed and developed totally within confines of the C++ standards committee. This effectively marginalizes Boost - that is, makes it less relevant and important. c) This effort by the committee is basically failing. It's creating the possibility that C++ will evolve into an ever larger and incomprehensible bag of disjoint features than it already is. It makes it much harder to learn C++. This puts C++ on a slow train to oblivion. This is not unusual with successful projects which expand their scope - as the committee has done. It's especially common for organizations run as a committee. Think large corporations: Kodak, Sears, All government organizations, universities - etc. All one has to do to see this is look at the papers list for the San Diego meeting. Also look at P0977r0. Consider that it take the committee 10 years for a proposal to evolve into something that can be delivered to users. It even takes 10 years to include something which is already in use by 100's of thousands of programmers - ASIO. Of course the C++ committee won't address the situation. Committees don't do that. They think they can remain relevant by expanding scope. and lo and behold, now they want to expand scope again to include tooling. Wake up and smell the coffee people. Learn to prioritize and limit the scope of your actions to that which only you can do. This would be better for C++. Do less - get more done! d) Boost can accept, review and deliver a new library in a year. Hence Boost has a reason to continue and exist. But Boost is also a committee - albeit a better designed one. It has to evolve as well. I think it can evolve if we continue to work on the stuff we've been successful at while at the same time experimenting with new ideas. Robert Ramey

23 70

warning: non-free usage requirements <threading>multi ignored
by blubee blubeeme 25 Oct '18

25 Oct '18

Hello I am trying to build boost from git clone I run bootstrap.sh with these flags ```shell ./bootstrap.sh \ --prefix=/usr/local \ --with-toolset=clang \ --with-icu=/usr/local \ --with-python=python27 \ ``` After boostrapping I append ```shell "using mpi ;" >> ./project-config.jam ``` There's two issues with that 1)icu isn't found even though icu headers are in /usr/local/unicode/ 2)I get this this warning ```error warning: non-free usage requirements <threading>multi ignored warning: in main-target boost_mpi_python at libs/mpi/build/Jamfile.v2:144 ``` Which I tracked down to this issue: http://boost.2283326.n4.nabble.com/explicitly-specified-values-of-non-free-… That thread leaves the issue unresolved and just throws a warning instead of failing. ```shell ./bjam \ --prefix=/usr/local \ --layout=system \ -d4 \ --toolset=clang \ --build-dir=./build \ --stagedir=/opt/boost \ -j4 \ include=/usr/local/include/unicode \ link=shared \ threading=multi \ stage \ ``` bjam output ```shell Performing configuration checks - default address-model : 64-bit - default architecture : x86 - symlinks supported : yes - C++11 mutex : yes - lockfree boost::atomic_flag : no - Boost.Config Feature Check: cxx11_auto_declarations : yes - Boost.Config Feature Check: cxx11_constexpr : yes - Boost.Config Feature Check: cxx11_defaulted_functions : yes - Boost.Config Feature Check: cxx11_final : yes - Boost.Config Feature Check: cxx11_hdr_mutex : yes - Boost.Config Feature Check: cxx11_hdr_tuple : yes - Boost.Config Feature Check: cxx11_lambdas : yes - Boost.Config Feature Check: cxx11_noexcept : yes - Boost.Config Feature Check: cxx11_nullptr : yes - Boost.Config Feature Check: cxx11_rvalue_references : yes - Boost.Config Feature Check: cxx11_template_aliases : yes - Boost.Config Feature Check: cxx11_thread_local : yes - Boost.Config Feature Check: cxx11_variadic_templates : yes - has_icu builds : yes warning: non-free usage requirements <threading>multi ignored warning: in main-target mpi at project-config.jam:42 warning: non-free usage requirements <threading>multi ignored warning: in main-target boost_mpi at libs/mpi/build/Jamfile.v2:119 - zlib : yes - bzip2 : yes - lzma : yes - zstd : no - iconv (libc) : yes - icu : no - icu (lib64) : no - xlocale supported : yes - native-atomic-int32-supported : yes - native-syslog-supported : yes - pthread-supports-robust-mutexes : yes - compiler-supports-ssse3 : yes - compiler-supports-avx2 : yes - gcc visibility : yes - long double support : no warning: non-free usage requirements <threading>multi ignored warning: in main-target boost_mpi_python at libs/mpi/build/Jamfile.v2:144 - libbacktrace builds : no - addr2line builds : yes - WinDbg builds : no - WinDbgCached builds : no - BOOST_COMP_GNUC >= 4.3.0 : no Component configuration: - atomic : building - chrono : building - container : building - context : building - contract : building - coroutine : building - date_time : building - exception : building - fiber : building - filesystem : building - graph : building - graph_parallel : building - iostreams : building - locale : building - log : building - math : building - mpi : building - program_options : building - python : building - random : building - regex : building - serialization : building - stacktrace : building - system : building - test : building - thread : building - timer : building - type_erasure : building - wave : building ``` I do have a working installation of openmpi installed in /usr/local and mpicxx is in my path from following the directions here: https://www.boost.org/doc/libs/1_64_0/doc/html/mpi/getting_started.html#mpi… in the end the build errors out ```shell 0.003049 sec system; 0.000000 sec user; 3.078255 sec clock Using shell: /bin/sh -c argv[0] = '/bin/sh' argv[1] = '-c' argv[2] = ' ln -f -s 'libboost_wave.so.1.69.0' '/wrkdirs/usr/ports/devel/boost-devel/work/stage/lib/libboost_wave.so' ' ln-UNIX /wrkdirs/usr/ports/devel/boost-devel/work/stage/lib/libboost_wave.so ln -f -s 'libboost_wave.so.1.69.0' '/wrkdirs/usr/ports/devel/boost-devel/work/stage/lib/libboost_wave.so' 0.001905 sec system; 0.000000 sec user; 1.957884 sec clock ...failed updating 86 targets... ...skipped 17 targets... ...updated 1147 targets... *** [do-build] Error code 1 make: stopped in /usr/ports/devel/boost-devel 1 error ``` two questions: 1) How do I solve the non-free usage requirements warning 2) Why isn't icu being picked up? github issue:: https://github.com/boostorg/boost/issues/210

1 0

Library devs only: Boost v2.x distro design questions
by Niall Douglas 24 Oct '18

24 Oct '18

Splitting this off from the other thread, can I get feedback from Boost library maintainers ONLY. Not users, not non-maintainers. Q0: Are you willing to do the work to adapt your library for any Boost v2.x distro if it were to happen? Q1: Would you prefer a new, separate Boost v2.x distro in parallel to the v1.x distro, or to keep everything within one v1.x distro? Q2: Would you be intending to keep your library inside Boost v1.x, move it exclusively to Boost v2.x, or have it exist in both Boost v1.x and v2.x but with different defaults configured? Also, would the version in v1.x be hard forked from any v2.x edition i.e. the v1.x edition would get orphaned? Q3: What C++ standard should Boost v2.x's master build system be defaulted to? C++ 11, 14, 17 or 20? Q4: Should Boost v2.x use a boost2 namespace, or namespace boost { inline namespace v2 { }}? (This affects whether Boost v2 and v1 editions of your library can be used within the same translation unit) Q5: What master buildsystem should Boost v2.x use? Boost.Build, cmake, Build2, something else? Q6: Should Boost v2.x's libraries auto integrate individually into some package manager? If so, which ones do you intend to support? Q7: Should Boost v2.x have official release versions done by release managers, or should it be a rolling release of "whatever last passed the CI @ 100%"? Note that you can have this, and have official release versions of "especially known good" editions too. Q8: Should Boost v2.x use a local HTML server to serve documentation, and the static HTML docs be dispensed with as a requirement? Q9: What are your feelings towards the use of Python to script infrastructure and tooling in any Boost v2.x? For example, Python to run a local HTML server to serve documentation locally, or Python to build a release etc Q10: What parts of core Boost are you utterly dependent upon, and would absolutely need ported to any Boost v2.x as no STL alternatives exist? I could go on, but let's stop there for now. Niall

2 4

Re: [boost] [release] 1.69.0 deadline for new libraries approaching
by Peter Dimov 24 Oct '18

24 Oct '18

> Robert Ramey wrote: > > On 10/22/18 10:19 AM, Peter Dimov via Boost wrote: > > > Marshall Clow wrote: > > > > > >> * 24-Oct: Boost 1.69.0 closed for new libraries and breaking changes > > > > > > OK... do we want CMake config files installed by 1.69 or not, then? > > > > I'd like to know this as well. If so, I presume that we can consider > > the Boost/CMake issues resolved and we can just move on from this? > > I doubt it. The CMake issue is much bigger than this. To expand on that: The Boost/CMake issues concern four scenarios: 1. CMake users who want to use a pre-built Boost from CMake, after installing it either with `b2 install`, as usual, or via some other mechanism; 2. CMake users who want to use Boost (or an individual Boost library) from CMake without building it with b2 and installing it, but as a subproject, built by CMake; 3. Building and installing Boost with CMake, replacing the current Boost.Build building/installing infrastructure; 4. Testing Boost with CMake, replacing the current Boost.Build testing infrastructure. Installing CMake config files as part of `b2 install` falls into scenario number 1. Boost is still built with Boost.Build as always, it's just that in addition to libboost_foo.a, the user also gets libboost_foo.cmake, which allows him to do `find_package(boost_foo)` from his CMakeLists.txt file. Nothing more than that. This doesn't affect, doesn't target, and doesn't address, scenarios 2-4 at all.

8 25

boost-cmake and quickbook
by Raffi Enficiaud 23 Oct '18

23 Oct '18

On 23.10.18 21:29, Edward Diener via Boost wrote: > On 10/23/2018 2:36 PM, Robert Ramey via Boost wrote: >> On 10/23/18 11:17 AM, Peter Dimov via Boost wrote: >>> Robert Ramey wrote: >>> >>>> And I place the html and pdf versions into the repo so users don't have to build it. >>> >>> Placing the .html/pdf files into the repo is one - unquestionably modular - way to do it, but it does have its downsides. >> >> Both true. >> >> downside >> - "wastes" a lot of space >> - redundant - docs could get out sync with the code. >> >> >> upside >> >> - current documentation is always available to the user. In the two libraries of mine - documentation is an important part and I don't think the either would be usable without them. >> - only needs to be built on one machine no hassle for users >> - document build doesn't have to be "portable" >> - potential users can easily browse the documentation before they clone/download the package. This works well with github. I think this is very valuable - especialy for safe_numerics which most people don't actually see the need for. Call it a sales tool. > > I am sure you know that github already has support for viewing the documentation via the github io mechanism, so your last '-' item is not really applicable to your argument. > > My argument is simply that lots and lots of libraries use Boost Build to generate the docs, very often through the quickbook -> docbook -> pdf/html mechanism and unless we are going to continue to do it that way when Boost uses CMake we will eventually need a way to duplicate the Boost Build mechanism for creating the docs in CMake. > > Nonetheless I continue to believe that the move to CMake by Boost should be achieved in small steps, so that we can assure success in one step for all libraries before we even think about attempting the next. I still have the same fear that trying to accomplish everything at one time will mean that nothing really will ever get done. I only added item 5) to Peter's list because that is something we will eventually have to decide about. [sorry for multiple posting] Talking about small steps, feel free to copy paste this wherever you need it: https://github.com/raffienficiaud/boost-cmake/blob/master/boost-cmake/quick… I compiled Boost.Test documentation with this, this is fully cmake and it does the catalog generation on the fly. This is a small step, usually this is where collaboration starts, since I do not have all the knowledge of quickbook/docbook nor the bandwidth ATM. *But* if somebody is kind enough to assist me on this, in particular explaining me if we would want --stringparam chunk.first.sections "1" --stringparam chunk.section.depth "4" --stringparam generate.section.toc.level "3" --stringparam html.stylesheet "boostbook.css" --stringparam toc.max.depth "3" --stringparam toc.section.depth "10" to be exposed when compiling a documentation, or how to run the doxygen part, then porting things to cmake will be definitely faster. Raffi _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

[preprocessor] vc++ using the experimental preprocessor
by Edward Diener 23 Oct '18

23 Oct '18

I have updated on the 'develop' branch Boost PP code that will use the vc++ C++ standard conforming preprocessor in VS2017 15.8 and above, as explained at https://blogs.msdn.microsoft.com/vcblog/2018/07/06/msvc-preprocessor-progre…. The code essentially treats vc++ in this mode as a strictly standard conforming preprocessor. There is the switch of /experimental:preprocessor which turns on the new preprocessor for the end-user, else the normal non-standard vc++ preprocessor is still the current default. BTW I tried to post a comment to the link above, explaining that the test posted in the article for the new preprocessor was wrong, but for whatever reason it never was actually posted as a comment. Nonetheless I got it right for myself in the Boost PP code in its config.hpp, so I am not going to worry about the fact that others may use the erroneous test in the article in their code. The change I made to Boost PP does not affect any other compiler, including vc++ in normal non-standard preprocessor mode. I have no idea if any regression tests for msvc-14.1 are made with this /experimental:preprocessor switch, but I will wait for 'develop' to cycle through before merging to 'master' in Boost PP. My preprocessor tests show four failures with the new vc++ preprocessor. Two of the failures are based on the fact that the test code expects a macro called with the wrong number of arguments to produce a compiler error and not just a warning. But since I have been told, vis-a-vis the same situation occurring for the Oracle C ++ compiler, that compilers are allowed under the C++ standard to produce a warning and just "chug" on, even if producing macro output that is certainly not what the programmer intended, rather than produce a compilation error maybe I just need to eliminate those tests, as important as I think they are. The other two failures are with the BOOST_PP_ITERATE macro and corresponding structures. The new preprocessor also erroneously continues to give a number of argument mismatch warnings in cases where it does not really exist, similar to the non-standard preprocessor, but since it "chugs" on despite the false warnings it ends up producing the correct output anyway. I have already posted a bug report about the fact that the new preprocessor gives a warning and continues when a macro is called with the wrong number of arguments. The other problem with BOOST_PP_ITERATE will be harder to determine because the iterate mechanism in Boost PP is fairly complex and I will need to figure out what is causing it and reduce the failure to a much simpler form in order to report it. As far as the compiler warnings of the wrong number of arguments when they do not exist, again I will have to try and figure out why and report the bug(s) to Microsoft. If anyone wants to try this out on Boost PP 'develop' feel free to do so. You will need to invoke the msvc-14.1 toolset in Boost Build with the /experimental:preprocessor switch and you will need to upgrade VS2017 to 15.8 or above. You can tell whether you have succeeded invoking the Boost PP tests with the new preprocessor by looking at the run output of the config_info test. If the BOOST_PP_CONFIG_FLAGS() is 0x0001 it is the new preprocessor, else it is the default non-standard preprocessor (0x0004).

6 13

Invitation to join the C++ chat community!
by Vinnie Falco 23 Oct '18

23 Oct '18

All: Hi there. I would like to personally invite all of the Boost authors, participants on the mailing list, and interested parties to join the most popular C++ Slack workspace, where many lively technical discussions related to C++ and its ecosystem take place. There are channels for everyone, especially the #boost channel, but also channels for WG21 committee discussions such as #future_standard and #wg21. There's even an #sg14 ! You can learn more and request a free invitation here: <http://slack.cpp.al> This workspace is sponsored by the C++ Alliance, a non-profit organization which promotes and advances the C++ language and provides educational resources. Find out more about the Alliance here: <http://cpp.al> Regards

3 5

Development Calendar is empty
by James E. King III 23 Oct '18

23 Oct '18

When is the next freeze or release? https://www.boost.org/development/index.html - Jim

5 5

[histogram] Finalising version for submission
by Hans Dembinski 22 Oct '18

22 Oct '18

Hi all, I have a general question regarding the submission process on how to deal with extensions of the library. I am currently working on the points raised in the review. Clearly, the bugs need to be fixed and the documentation improved where it was lacking. So the procedure is clear in that regard, but the final version to be included in Boost will also have more features, the main ones are: - support for profiles and in general arbitrary accumulators as bin "counter" types - in particular any Boost.Accumulator - allow arbitrary metadata (or no metadata at all) to be associated with the builtin axes types, instead of just supporting a string label (the metadata type will be a template parameter) - use axis types through a traits-interface to make adding custom axis types really easy (a minimal axis only needs to implement `int operator()(something) const` and `unsigned size() const`, everything else is optional) - use storage types through a traits-interface to allow arbitrary STL and Boost containers as storage backends - add a support library for typical calculations done with histograms, like reducing a high-dimensional histogram to a lower-dimensional histogram, shrink an axis, etc - growing axes that increase the number of bins while the histogram is filled I started working on these features and switching to C++14 would simplify the implementation a lot, thanks to generic lambdas and return type deduction. So I would like to raise the requirement for the final library from C++11 to C++14. Since these are substantial changes, is another formal review of the final version required? In any case, I will request informal feedback on the final version on the list before histogram is released with Boost for the first time. Best regards, Hans

5 10

[all] Hidden visibility is on by deafult
by Antony Polukhin 22 Oct '18

22 Oct '18

Good news everyone! I'd like to announce that now Boost libraries are build with hidden visibility by deafult. Many thanks to Andrey Semashev for providing the required patches and PR to fix some builds, and to Glen Fernandes for merging. Separate thanks to all the Boosters who reported/fixed visibility related issues.

3 2

[review][histogram] Histogram Review Results
by Mateusz Loskot 22 Oct '18

22 Oct '18

Hi Everyone, Please, welcome the Histogram library to the Boost collection! Thank you Hans for submitting a high-quality library for review. Thank you to the reviewers as well as those who just exchanged their comments on numerous aspects of the library and participated in the fruitful discussions. Among reviewers, we can recognise veteran Boost contributors and authors as well as experts in the fields of statistics, raster analysis, including authors of histogram-oriented software packages. ---------------------------------------- Official reviews and votes: ---------------------------------------- 1. Klemens David Morgenstern - ACCEPT 2. Jim Pivarski (off-list) - ACCEPT 3. Bjorn Reese - ACCEPT conditionally 4. Steven Watanabe - ACCEPT conditionally 5. Alex Hagen-Zanker - ACCEPT Non-review participations: 1. Andrea Bocci (off-list) 2. degski 3. Glen Fernandes (off-list) 4. Gavin Lambert 5. Seth 6. Mateusz Loskot ---------------------------------------- Acceptance conditions ---------------------------------------- Two reviews stated conditions which are important fulfilled: Bjorn Reese - Reference documentation is finalized Steven Watanabe - Various exception safety and memory issues must be fixed. - The reference documentation must be completed. Specifically, various preconditions, requirements, and assumptions must be made explicit. I believe those are not controversial at all and Hans is also interested in addressing those requests. ---------------------------------------- Concerns and comments ---------------------------------------- Jim Pivarski mentioned importance of profile plots as fundamental enough that they should be part of the feature set. In short term, the profile plots can be implemented as a new storage type, using the extension capabilities. Similarly, some concurrent applications would need atomic-valued bins, but these, too, can be storage types. Bjorn Reese pointed out some aspects of the design that makes the library not work very well with STL algorithms. Bjorn strongly recommended that the default storage policy is changed to remove some of those limitations. Steven Watanabe provided Hans with large number of very detailed comments and fixes (eg. do not call destructor which has been fixed), suggestions how to improve run-fail tests and serialization tests. Alex Hagen-Zanker commented that range-based for-loops support could be improved, suggested to provide separate ranges or views for certain histogram access scenarios. Another important theme of Alex' review was Histogram applicability for moving window type analysis. Then, Alex requested clarification on choosing variance based on the Poisson distribution instead of the binomial distribution. degski suggested to look for some "low hanging fruits" in C++14 and/or C++17, the library could potentially benefit from, pushing the 'modern C++' trait of the library even further. Gavin Lambert suggested to allow use of quantity types like Boost.Units. Glen Fernandes mentioned he would raise allocator model support issues or relaxing the requirement that the pointer must be a raw pointer of type value_type*. Glen mentioned he may even be available to help. Hans has already addressed many of the suggestions and issues or planned related features for future releases of the library. Issues resulting from the feedback received during the review can be tracked and further discussed on GitHub, labelled with boost-review: https://github.com/HDembinski/histogram/labels/boost-review ---------------------------------------- The Upsides ---------------------------------------- There were lots of great things said about the Histogram library: - design: excellent, clean, simple and extensible in principle - useful and well-designed features - geared towards readability and performance - very good documentation ---------------------------------------- Final Thoughts ---------------------------------------- Reviewers are worth their weight in gold nowadays. Once again, I'd like to thank all participants for great amount of quality feedback that already led to important improvements in the Histogram library in very timely manner - thank you Hans! The Histogram library is a valuable addition to Boost. Best regards, -- Mateusz Loskot Review Manager for the proposed Boost.Histogram

2 1

Re: [boost] Mail List Migration - Update
by Tom Kent 21 Oct '18

21 Oct '18

> > The Boost mail lists are now migrated to a new set of servers. > This change affected all mail lists and web resources (signing up, > changing passwords, moderator access, archives...) that were associated > with the domain lists.boost.org . > If you are having difficulties, please drop me an email. (Oh the irony) > Happy coding! > michael > -- > Michael Caisse > Ciere Consulting > ciere.com Michael- I've tried to send e-mail to a couple lists with boost over the past few days. On Tuesday, Oct 16, I sent an e-mail at 19:21 CDT to the boost(a)lists.boost.org list, "Non-ASCII Path Names in Repo" [1]. It seemed to take the better part of a day to be received by the list. I remember it taking a long time (>24hrs), but I can't prove that. However, if you click the previous message/next message links on [1], you'll see that both of those messages (including the one previous!) are timestamped several hours after mine. Now, as of Friday, Oct 19, at 06:59 CDT I had sent another e-mail, this time to boost-testing(a)lists.boost.org. As of writing this e-mail (07:35 CDT, Sunday Oct 21), it still hasn't shown up on the testing list [2], and I haven't received an e-mail saying that it was received by the list. Any thoughts as to what might be happening here? In the past (including earlier this month for boost-testing), I was able to post without issue from this address (lists(a)teeks99.com) to both of these lists. Thanks, Tom [1] https://lists.boost.org/Archives/boost/2018/10/243784.php [2] https://lists.boost.org/boost-testing/2018/10/index.php

1 0

Allow LICENSE file per a library repository (PR #374)
by Mateusz Loskot 21 Oct '18

21 Oct '18

Hi, I'd like to bring this proposal to the community's attention: https://github.com/boostorg/website/pull/374 BTW, from time to time, while I looking at various requirements I try to refresh those outdated and catch up with the reality. I take baby steps. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

Re: [boost] Fwd: Installing CMake configuration files
by Peter Dimov 20 Oct '18

20 Oct '18

Steven Watanabe wrote: > Just a couple comments: ... > * I'm not fond of the ROOT parameter for boost-install.boost-install. > * Dependencies can be referenced with /boost/$(deps)//[stage|install] > * You can find the full path to the boost-install.jam with > [ path.root [ modules.binding $(__name__) ] [ path.pwd ] ] > This avoids hard-coding the location of boost_install relative > to the superproject. Actually, [ modules.binding $(__name__) ] seems to return an absolute path, so path.root/path.pwd may not be needed here? boostcpp.jam does BOOST_ROOT = [ modules.binding $(__name__) ] ; BOOST_ROOT = $(BOOST_ROOT:D) ; which kind of implies that it relies on getting the absolute path. > * That just leaves the stage directory, which is tied to the > project root, and should perhaps be calculated in Jamroot > instead of in boost_install. The stage directory needs to be retrieved from boostcpp, but boostcpp just sets it to "stage", which only works from top-level. It should probably use $(BOOST_ROOT)/stage, and then other modules can peek for it. There are other things that are needlessly replicated - install-header-subdir, install-default-prefix. All of these need to be peekable from a canonical location. > * This seems to handle --layout=versioned, but I'm not clear on > how well it handles --layout=system where we expect to use a > single compiled library for all configurations. It worked when I tried it. Note that you can have two libraries with --layout=system, not just one; libfoo.a and foo.so. > * Are the error messages that you get from CMake when there > isn't a configuration that matches the request intelligible? Not very. There's Boost_DEBUG, which tells you why something was skipped, but ideally, it needs to detect the case when no variant matched, and _then_ tell you why things were skipped without your having to set Boost_DEBUG beforehand. I haven't gotten that far yet; usability can be improved once we have it working. > It looks like the target will exist but will silently do nothing? Yes, you get a link error. > What if something goes wrong and there are multiple matches? I haven't encountered this so far :-) although it's possible in principle because at the moment I ignore some "non salient" properties. > * If generate-cmake-config takes the library as a source, > then it's possible to derive both the library dependencies > and the exact library name from the library target. The > dependencies can be found at the virtual target level in > generate-cmake-config, and the exact file name will appear > as the source in generate-cmake-config-. Doing it this way > also has the side effect that the CMake configuration won't > be installed if the library fails to build, which may be a > good thing. These may take me a while to figure out. :-)

3 15

[asio] Issues piling up
by Vinnie Falco 20 Oct '18

20 Oct '18

There are issues which are years old which have been lingering in the Boost.Asio repository, and there are also old issues in the stand-alone Asio repository. It seems like these are being ignored, is there any strategy for addressing this? Examples: This one is going on a year: <https://github.com/boostorg/asio/issues/77> Two years: <https://github.com/chriskohlhoff/asio/issues/124> Thanks

10 16

Re: [boost] Fwd: Installing CMake configuration files
by Peter Dimov 20 Oct '18

20 Oct '18

> Yeah, I haven't been able to figure this part out. How do I pass the > $(sources) from generate-cmake-variant to generate-cmake-variant-'s > sources? The sources - in this case $(lib-target) go here, after `non-scanning-action`: local a = [ new non-scanning-action $(lib-target) : boost-install.generate-cmake-variant- : $(property-set) ] ; :-)

1 0

Installing CMake configuration files
by Peter Dimov 19 Oct '18

19 Oct '18

I've taken another stab at installing CMake configuration files along with the libraries in `b2 install`. CMake configuration files are .cmake files, typically installed into $prefix/lib or $prefix/lib/cmake, that allow f.ex. `find_package(boost_system)` in a CMakeLists.txt file to find the installed Boost.System library and declare a CMake target Boost::system that refers to it. CMake targets can then link to Boost::system and all is well. The work in its current state is available on the feature/cmake-config branch of the superproject: git clone --recursive -b feature/cmake-config https://github.com/boostorg/boost cd boost bootstrap b2 --prefix=... install After that .../lib should contain the libraries and .../lib/cmake - the config files. Then from CMake cmake -DCMAKE_INSTALL_PREFIX=... .. as usual. See for example the test scripts at https://github.com/boostorg/boost_install/blob/master/.travis.yml#L60 and https://github.com/boostorg/boost_install/blob/master/appveyor.yml#L40 Since `b2 install` installs more than one library variant, the CMake configurations need to pick the correct one and to do so look at (a subset of) the FindBoost-compatible variables as described at: https://github.com/Kitware/CMake/blob/master/Modules/FindBoost.cmake#L122 Boost_USE_DEBUG_LIBS, Boost_USE_RELEASE_LIBS, Boost_USE_STATIC_LIBS, Boost_USE_STATIC_RUNTIME, Boost_COMPILER, Boost_DEBUG are honored and have the same meaning as in FindBoost. Boost_USE_MULTITHREADED and Boost_USE_DEBUG_RUNTIME are presently ignored, but probably shouldn't be. :-) The default of Boost_USE_STATIC_LIBS being OFF is a bit inconvenient on Windows, where without `--build-type=complete` our installation only gives you static libraries, and there are suggestions to respect it being ON or OFF, but when not set, to look at BUILD_SHARED_LIBS instead. Under the hood this represents a refactoring of the current centralized installation approach in which the superproject staged and installed the libraries on `b2 stage` and `b2 install`. Now the top level stage and install targets just delegate to each library's stage and install targets, which are responsible for staging/installing that particular library, its CMake config, and its dependencies. These library-level stage and install targets are created by the helper b2 rule boost-install, which already existed (in Jamroot), but is now much enhanced and lives in its own module tools/boost_install. In addition, a metalibrary libs/headers is introduced, which corresponds to the headers as present in a release (in subdirectory boost/) or as installed by `b2 install`. Its install target, in fact, installs the headers, and its stage target, currently empty, should probably assume the function of linking the headers (which at the moment also lives in Jamroot.) At some future point, when we decide to switch to releasing the headers in their original libs/$lib/include locations, the install target of a library will just copy that library's headers; but we aren't there yet. The header-only libraries are used from CMake by finding the package boost_headers and linking to the target Boost::headers. I've deliberately not done anything about Boost::boost and find_package(Boost), to allow FindBoost.cmake to delegate to the config files if present (when Boost 1.69/1.70 or higher is installed), while preserving backward compatibility (when 1.68 or lower is installed.)

6 13

test message - please ignore
by Robert Ramey 19 Oct '18

19 Oct '18

just to see if my newsgroup interface is working. Robert Ramey

1 0

[python] Checking Python version
by Edward Diener 18 Oct '18

18 Oct '18

How do I check the Python major version in code when using Boost.Python ? I know there is a way to do it through a preprocessor define by including the CPathon patchlevel.h file but I would rather not include low-level Python files if Boost.Python has some way of doing it.

2 1

[test] How to execute shell commands
by Mike Dev 18 Oct '18

18 Oct '18

As an extension to my previous question: Does the boost test framework provide an integrated mechanism to get the binary directory (the directory where the currently running test executable is placed) and/or the source directory (where the jam-file resides that defined the test)? Best Mike

4 5

[intrusive] static_assert(sizeof(caster)==sizeof(int))
by Vinnie Falco 18 Oct '18

18 Oct '18

A user is reporting a static assert on compilation: <https://github.com/boostorg/beast/issues/1270> Any ideas? Thanks

2 1

Boost header isolation testing
by James E. King III 16 Oct '18

16 Oct '18

In the winapi project there's a neat little Jamfile rule that will ensure each public header will compile properly (i.e. it is not missing any #include statements). I pulled this into uuid when I started maintaining it, and I find myself pulling it into another repository. It would be nice to have this as a standard Boost.Build rule that one could easily add to test Jamfiles. Is there anything like this that exists right now in Boost.Build? - Jim

6 9

Boost CMake support - Request for Comment
by Robert Ramey 16 Oct '18

16 Oct '18

Background ========== My personal knowledge of build systems is somewhat limited. a) I don't really understand CMake all that well. I have made CMakeLists.txt files for both the serialization library and the safe numerics libraries as an aid to build and maintain IDE and make files used in running tests and posting results to CDash. b) I don't really understand our current system, Boost Build, very well either. I've made jam files for building and running tests for the serialization and safe numerics libraries. c) I recently reviewed C++Now 2017: Daniel Pfeifer's excellent video from C++Now 2017 “Effective CMake" - https://www.youtube.com/watch?v=bsXLMQ6WgIk . I recommend it highly. Despite my lack of knowledge in this area, or perhaps because of it, I've volunteered to direct the effort to evolve Boost so that users of Boost can avail themselves of the benefits of CMake. This effort will be organized as follows: a) A discussion on the boost developers mailing list with the goal of reaching a consensus as to what benefits CMake can and should provide to users and developers of Boost. This effort will commence with the posting of this notice. I hope that this discussion can be more or less resolved within 30 days. b) I will then synthesize from the above discussion a call for proposals which lists the requirements and requirements. c) Those proposing CMake for boost will have approximately 90 days to prepare their proposals. Their proposal are expected to look similar to a boost library proposal. That is they are expected to have some (CMake) code, along with tests, documentation including tutorials and reference. This is only an expectation. It's conceivable that such a proposal might only contain conventions and and samples of what boost library should contain to fulfill the requirements. As with boost libraries, submissions are not required to totally complete. But they have to be sufficiently complete to convince reviewers the the submission fulfills the stated requirements and can be finished in good time. d) After the 90 day period, submissions will be reviewed simultaneously. Note that this is at a variance from normal boost procedure of reviewing submissions one at a time. Since we expect to receive a number of submissions and only one can be accepted, the normal boost protocol can't really function. Target date for this review is 1 February 2019. e) After the review period the review manager will prepare a report which includes the decision of which submission will be accepted into the official boost distribution. Currently, I, Robert Ramey, expect to be review manager. However, it's possible that this by the time the review is undertaken, this coveted position could be assigned to some more worthy candidate. Scope, Requirements and Features ================================ We presume that submissions will fulfill the applicable requirements of any boost submission. In addition we would like to see the following addressed. Library Build ------------- “Effective CMake" - https://www.youtube.com/watch?v=bsXLMQ6WgIk Recommends that all libraries - including header only libraries have a CMakeList.txt file. What should this include for Boost Libraries? Library Test ------------ Should facilities for "testing" be only done by developers? or should users who acquire library packages also be able to test libraries. Should CMake testing results posting be used - CDASH? Should we just skip the issue of Library Testing and continue to depend on Boost Build. Library Packaging ----------------- Is the library packaging facility provide by CMake - CPACK - useful to boost. Should boost libraries be updated to support it? Dependencies ------------ If the above is implemented, can we depend upon CMake to handle library dependencies? Or does some special functionality Do circular dependencies constitute a problem? Modularity ---------- Currently boost is organized as a tightly integrated group of libraries. This organization manifests itself in a number of ways. We have a Boost "super project" in github. Boost libraries are "sub projects" of this super project. This known structure is exploited by and depended upon by boost tools. Should CMake support continue this policy/design. We distribute boost as "super project". Should we continue to do this or distribute libraries on a library by library basis. Does CMake/CPACK etc. make this "simple"? Documentation/testing --------------------- What support should be require for uses of Boost CMake implementation. Documentation, examples, templates for helping library developers. How should the CMake design/implementation be tested? Other considerations -------------------- add your requirement/features here. Useful Resources =============== “Effective CMake" - https://www.youtube.com/watch?v=bsXLMQ6WgIk https://gist.github.com/mbinna/c61dbb39bca0e4fb7d1f73b0d66a4fd1 https://github.com/purpleKarrot/Boost.CMake https://www.youtube.com/watch?v=eC9-iRN2b04 Please try to keep this discussion on this list. I know that there has been a lot going on on slack. But having it in two places makes it harder for me to review and summarize. Also slack doesn't conveniently maintain comment hierarchy. So please try to keep this discussion on this list. Robert Ramey

15 47

Re: [boost] "peer reviewed" - Rights and responsibilities of maintainers
by Bjorn Reese 16 Oct '18

16 Oct '18

On 10/16/18 9:59 AM, Alexander Grund via Boost wrote: > So again: What is the Boost course on reviews of existing libraries and > the statement on the rights and responsibilities of maintainers? https://www.boost.org/community/reviews.html#Maintainer

4 4

[program_options] custom validator overrides
by Roger Martin 16 Oct '18

16 Oct '18

Hi, The Custom Validators documentation https://www.boost.org/doc/libs/1_68_0/doc/html/program_options/howto.html shows void validate(boost::any& v, const std::vector<std::string>& values, magic_number* target_type, int) { but the possible templates don't match; the last variable type is an int; the key is matching this last type: int goes with std::vector<T>* long goes with T* it also seems possible to hit the void validate(boost::any& v, const std::vector<std::basic_string<charT> >& s, boost::optional<T>*, int) { where it then calls for get_single_string and if you are trying for a multitokens switch args, it'll throw " only takes a single argument". which also varies if it was parsed by command_line_parser or parse_config_file command_line_parser: vector size can >= 1 up to number of switch args parse_config_file: vector size ==1 no matter what the number of args are on the input. just one string with all switch args. This was tested with 1.65 yet I don't see anything changing in https://github.com/boostorg/program_options/blob/develop/include/boost/prog…

2 1

[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

bjam question about "requires" negation
by James E. King III 13 Oct '18

13 Oct '18

I want to run a test that should run without explicit operator conversion capability and fail to compile with explicit operation conversion capability, but I'm not sure how to negate the requires statement. I'm sure it's trivial but I found no examples. I tried a bunch of things but none worked. [ run implicit_conversion.cpp : : : [ requires NO cxx11_explicit_conversion_operators ] : implicit_conversion ] [ compile-fail implicit_conversion.cpp : [ requires cxx11_explicit_conversion_operators ] : explicit_conversion ] How do I properly implement the "NO" part? Thanks, Jim

2 1

[parameter] An offer to help maintain and improve the library
by Cromwell Enage 13 Oct '18

13 Oct '18

Hello, everyone. It took me a while to get around to this, but here goes. I've been a long-time user of Boost libraries, although life events imposed a bit of a hiatus until recently. But now I have the opportunity to help out some more, and one of the ways I want to give back to this community is by helping to maintain and improve Boost.Parameter. I participated in the review of this library before it was accepted, so I'm familiar with its capabilities and code structure. In addition to fixing any bugs and handling pull requests, I'd like to make the following improvements, which I will summarize here: * Add macros to generate Boost.Parameter-enabled function call operators. * Add parameter category qualifiers "consume", "move_from", and "forward". (Current qualifiers are "in", "out", and "in_out".) * Fix parameter::parameters::operator() so that it also accepts non-const rvalues. * Be no longer bound by BOOST_PARAMETER_MAX_ARITY on compilers that support perfect forwarding. * Enable parameter::template_keyword<> to accept function types. * Remove the necessity of wrapping boost::ref() around non-const lvalues. I can discuss each of these bullet points in separate threads if necessary. I await your feedback! Cromwell D. Enage

2 1

Boost xxhr ? High level http client library
by Damien Buhl 13 Oct '18

13 Oct '18

Dear Boost, I've built an header-only library based on Boost.Beast which allows you to perform HTTP requests. It is implememented with two backends : * Boost.Beast for native builds. * XmlHttpRequest for WebAssembly (plans to migrate to fetch API which is richer) Actually Boost.Beast is a great lib, however it's API is thought to build HTTP centric app not just to make some simple HTTP call ( as for example urdl was ). xxhr on the other hand is about making it simple to call an HTTP service. Usage example : GET <https://nxxm.github.io/xxhr/html/namespacexxhr.html#a69bafa24d7c33b004a7de8…>( "http://httpbin.org/anything"s, on_response = [](auto&& resp) { std::cout << resp.text; }); I would be really interested in a pre-review or some feedback about it's API. The implementation merits more attention and can significantly be improved but this email is to grab a first feedback from the community. Documentation : https://nxxm.github.io/xxhr/ GitHub : https://github.com/nxxm/xxhr Example code relying on it : nxxm/gh <https://github.com/nxxm/gh>: partial GitHub API implementation Thanks for your time :) -- Damien Buhl Software Developer +33 6 77 43 10 05 https://nxxm.github.io/

3 5

Test matrix file read errors?
by James E. King III 11 Oct '18

11 Oct '18

I'm trying to look at the develop test matrix for a couple repositories and I am getting an error: Error extracting file: Error code 9 - The specified zipfile was not found *(the > file exists, so this is probably an error reading the file)*. https://www.boost.org/development/tests/develop/developer/date_time.html https://www.boost.org/development/tests/develop/developer/dynamic_bitset.ht… Thanks, Jim

2 1

[concept_check] CopyConstructible Concept Does Not Accept Lvalue Reference
by Qu Xing 11 Oct '18

11 Oct '18

Boost version: 1.67.0 Compiler: GCC 7.3.0 Environment: Cygwin on Windows 10 version 1709 In the Boost Concept Check library, CopyConstructible concept requires operator & applicable to the type being checked, and the return value is required to be convertible to pointer to the type. However, pointer to reference is not allowed in C++. This concept check fails to compile if applying to a lvalue reference type. On the other hand, is_copy_constructible<T> type trait class in the Boost Type Traits library and the standard C++ library both give positive result on lvalue reference types. For example, the following code snippet will fail to compile if T is a lvalue reference: #include <type_traits> #include <boost/static_assert.hpp> #include <boost/type_traits/is_copy_constructible.hpp> #include <boost/concept_check.hpp> #include <boost/concept/assert.hpp> template <typename T> void RequireCopyConstructible() { BOOST_STATIC_ASSERT(boost::is_copy_constructible<T>::value); // PASS on lvalue reference BOOST_STATIC_ASSERT(std::is_copy_constructible<T>::value); // PASS on lvalue reference BOOST_CONCEPT_ASSERT((boost::CopyConstructible<T>)); // FAIL on lvalue reference } void TestReference() { RequireCopyConstructible<int&>(); } Diagnosis message is generated as: "error: forming pointer to reference type ‘int&’". I think the operator & applicable requirement should be removed for CopyConstructible concept. Alternatively, adding a template specialization on lvalue reference type for CopyConstructible concept may work as well.

1 0

[config] really, really sticky issue with BOOST_SYMBOL_IMPORT
by Robert Ramey 10 Oct '18

10 Oct '18

For many, many years we've built the Boost serialization library with the macros for BOOST_SYMBOL_IMPORT and BOOST_SYMBOL_EXPORT set according to the instructions included in the boost/config documentation written by John Maddock. These set attributes for creating and using DLLS for windows and (used to) resolve to nothing on other systems. So far so good. At some point things changed for gcc compilers. Now it seems that BOOST_SYMBOL_IMPORT resolves to nothing and BOOST_SYMBOL_EXPORT resolves to : __attribute__ ((visibility("default"))) and BOOST_SYMBOL_IMPORT still resolves to nothing. OK - this has never been a problem. Now we have an extremely subtle issue which appears on linux systems with gcc. It's related to sequence of shared library loading and unloading. It shows up as a bunch of test failures for the test named test_exported_dll. A very astute user has determined that this can be "fixed" by defining BOOST_SYMBOL_IMPORT as __attribute__ ((visibility("default"))) as well. Question. should config/gcc be updated in this way? Also is it possible that this "fix" is just a fluke unrelated to the real source of the problem? Note that this issue predates the recent change to make -visibility=default which has, as one might expect, caused some issues. I believe that this situation is unrelated. Any help appreciated Robert Ramey reference: https://github.com/boostorg/serialization/issues/104#issuecomment-416948110

4 3

Tools to manage multiple repositories effectively?
by James E. King III 09 Oct '18

09 Oct '18

Hello, I am looking for tools that would allow me to create a portal and/or monitor the following properties of boost repositories. I am in the CMT and at least one fix that was in develop never made it into master for the 1.68.0 release, so I want to be able to see, at a glance, information about the boost repositories I care about in one place. There are about 20 repositories I regularly participate in now so a portal to show what I need to worry about would be useful. 1. How far behind is master (with respect to develop)? This would help identify which repositories are behind develop. Useful for ensuring things get into a release. 2. How many open pull requests? 3. How many new pull requests (within the last week)? 4. How many updated pull requests (within the last week)? 5. How many open issues? 6. How many new issues (within the last week)? 7. How many updated issues (within the last week)? "week" could be configured, perhaps month, or "since I last visited". Anybody know of any good tools or perhaps an existing site that can do this for a multi-repository solution? Thanks, Jim

3 2

[system] The new Boost.System is now ready
by Peter Dimov 09 Oct '18

09 Oct '18

The new Boost.System is now complete, on the develop branch: https://www.boost.org/doc/libs/develop/libs/system/ - header-only - even more constexpr than 1.68 - identifier-based category comparison - message() into a caller-supplied buffer - failed() The plan is to merge it to master at some point if no breakage is encountered on develop, so that it can go into the next release.

5 11

Export control classification number for boost
by DEMIAN, Beatrice (SOPRA STERIA GROUP SA) 08 Oct '18

08 Oct '18

Hi, We are using boost in one of our products, and are now in the process of collecting the information needed to export it. Can you tell me what the U.S. Export Control Classification Number (ECCN) for boost is, and whether a license exception may be used for it? Béatrice Demian On behalf of SOPRA STERIA Subcontractor for EYYW6 (AIRBUS France) The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.

2 1

[graph_parallel] property_serialize.hpp
by Peter Dimov 06 Oct '18

06 Oct '18

I'm looking at boost/pending/property_serialize.hpp, with the intent of moving it from Graph Parallel to Graph as it's included from a Graph header, and I see this: https://github.com/boostorg/graph_parallel/blob/develop/include/boost/pendi… #ifdef BOOST_GRAPH_USE_MPI namespace boost { namespace mpi { template<> struct is_mpi_datatype<boost::no_property> : mpl::true_ { }; } } // end namespace boost::mpi BOOST_IS_BITWISE_SERIALIZABLE(boost::no_property) BOOST_CLASS_IMPLEMENTATION(boost::no_property,object_serializable) BOOST_CLASS_TRACKING(boost::no_property,track_never) #endif // BOOST_GRAPH_USE_MPI What this does is, when BOOST_GRAPH_MPI is defined, it sets certain serialization properties for boost::no_property (is bitwise serializable, use object level versioning, never track address), but when BOOST_GRAPH_MPI is not defined, it doesn't. That is, the serialization format of boost::no_property changes on the basis of whether BOOST_GRAPH_MPI is defined. (It's the same for boost::property<>, above in the same file.) This does not seem correct to me. I would expect these serialization properties to be applied consistently regardless of whether MPI is used or not. But fixing this could conceivably break existing code that serializes and deserializes non-parallel graphs and relies on a certain format on disk. So... should we fix this or not?

2 2

Cycle between Graph and GraphParallel
by Peter Dimov 06 Oct '18

06 Oct '18

Currently we have a dependency cycle between `graph` and `graph_parallel`. It's not the only one, but it's notable with the fact that both libraries are buildable and we therefore can't ignore it as we can ignore cycles between header-only libraries that at release time become a single directory. In the particular, this impedes efforts to generate CMake config files. Under one scheme I'm currently working on, for instance, Boost.Python can't be installed because it tries to install Graph, which tries to install GraphParallel, which tries to install Graph. The cycle between these two is an interesting one. boost/graph/breadth_first_search.hpp does: #ifdef BOOST_GRAPH_USE_MPI # include <boost/graph/distributed/breadth_first_search.hpp> #endif at its end, and boost/graph/distributed/breadth_first_search.hpp does: #ifndef BOOST_GRAPH_USE_MPI #error "Parallel BGL files should not be included unless <boost/graph/use_mpi.hpp> has been included" #endif #include <boost/graph/breadth_first_search.hpp> at its very start. So these headers include each other. One would naively think that only the parallel header should include the normal one, but one is not well versed in graph library architectures, so one might quite possibly be missing something, or a lot. Comments?

4 4

Formal Review of Proposed Boost.Histogram Library is FINISHED
by Mateusz Loskot 05 Oct '18

05 Oct '18

Dear Boost Community, The formal review of Hans Dembinski's Histogram library has been completed. Here is the quantitative summary of feedback received: * Reviews: 1. Klemens David Morgenstern 2. Jim Pivarski (off-list via e-mail to Hans) 3. Björn Reese 4. Steven Watanabe 5. Alex Hagen-Zanker * Non-review participations: 1. degski 2. Gavin Lambert 3. Seth 4. Mateusz Loskot I believe I've collected the names/numbers right, but please let me know ASAP if you think otherwise. I'd like to thank all the participants for their time and efforts. I'm sure Hans received lots of valuable comments and suggestions. FYI, the discussion threads are still open for new posts. Those won't be taken into consideration towards the review result though. I will do my best to announce the review results next week. Mateusz Review Manager for the proposed Boost.Histogram -- Mateusz Loskot, http://mateusz.loskot.net

1 1

Twenty years and time to retire
by Beman Dawes 04 Oct '18

04 Oct '18

The idea behind Boost was hatched in March, 1998, and the proposal document <https://www.boost.org/users/proposal.pdf> was released May 6, 1998. That makes Boost twenty years old, and makes me twenty years older. It is high time I retire from Boost; I haven't been able to contribute for some time now. Thanks to all of you who made Boost such an overwhelming success in the past and will drive Boost forward into a bright future! --Beman

21 20

Release notes for release 1.69
by Paul A. Bristow 02 Oct '18

02 Oct '18

To avoid forgetting to do it when release time comes, I would like to add some Math and Multiprecision library release notes for the next release 1.69 Is providing a PR for this file that way to do this? ( I speak Quickbook ;-) ) https://github.com/boostorg/website/blob/master/feed/history/boost_1_69_0.q… (but it doesn't exist yet!) Thanks. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

1 0

[histogram] Variance
by Bjorn Reese 02 Oct '18

02 Oct '18

The variance of individual bins can be obtained when using the adaptive_storage (via h.at(i).variance().) I am trying to understand the overhead of this feature. If I interpret the code correctly, there is a space overhead because each counter has to keep track of both the count and the sum of squares. The computational overhead is that the sum of squares has to be calculated for each insertion. Is this correct? If so, is there any way to use the adaptive storage policy without variance? Furthermore, why does variance() return the sum of squares? Should this not be divided by the sample size?

5 8

[asio] Order of asynchronous messages
by Florian Lindner 01 Oct '18

01 Oct '18

Hello, in a distributed application (only local are network) we are experiencing issues which *may* stem from the order of asychronous messages sent over sockets. We create a send buffer: auto buffer = std::make_shared<std::vector<double>>(); and fill it: buffer.push_back(some_data). This buffer is then given to our communication routine request = aSend(*buffer, recipient); to keep the send buffer alive we place it in a class attribute: bufferedRequests.emplace_back(request, buffer); The aSend method from above works like (asio is boost asio, of course) PtrRequest aSend(std::vector<double> const & itemsToSend, int recipient) { PtrRequest request(new SocketRequest); asio::async_write(*_sockets[recipient], asio::buffer(itemsToSend), [request](boost::system::error_code const &, std::size_t) { std::static_pointer_cast<SocketRequest>(request)->complete(); }); return request; } This way, we can check for completion using request->test(), which is set from the callback request->complete(). For checking of completed requests we have a loop, which is called reqularly void checkBufferedRequests(bool blocking) { do { for (auto it = bufferedRequests.begin(); it != bufferedRequests.end();) { if (it->first->test()) it = bufferedRequests.erase(it); else ++it; } if (bufferedRequests.empty()) return; if (blocking) std::this_thread::yield(); // give up our time slice, so communication way work } while (blocking); } which operates on bufferedRequests, that is a list<pair<PtrRequest, PtrBuffer>>. We use that, so that the sending peer is not blocked by a slow receiving peer. The sockets are created like tcp::acceptor acceptor(*_ioService); { tcp::endpoint endpoint(tcp::v4(), _portNumber); acceptor.open(endpoint.protocol()); acceptor.set_option(tcp::acceptor::reuse_address(_reuseAddress)); acceptor.bind(endpoint); acceptor.listen(); } Now we are having problems with mangled data that are unexplainable right now. - Is the order of requests guaranteed to be preserved? I think so, based that asio works on TCP. - What happens if there is another read or write performed on the socket. I think that there is no way to guarantee that this does not interfere with the order of the asynchronous send or queued requests. Last but not least: Do you see any potential problems with that code? Thanks a lot! Florian

3 2

[container][interprocess][intrusive][move] Removing support for old compilers
by Ion Gaztañaga 01 Oct '18

01 Oct '18

Hi, My libraries have supported quite old compilers, starting from Visual 2003 and GCC 3.4 and I'm asking for feedback before I start dropping old compilers. The number of supported plus locally+regression tested versions has increased a lot these years and that's a lot of work with reduced benefits. I run locally for: - From Mingw GCC 3.4 to GCC 8.1, all released minor versions (combining C++03-C++11-C++14-C++14). - From MSVC 7.1 to MSVC 14.1, all released versions (default language standard). I also run boost regression tests for many of those compilers (see "igaztanaga-*" runners in https://www.boost.org/development/tests/master/developer/summary.html) The number of supported and tested compilers is now unmanageable for me as many of those have specific warnings/bugs that I try to fix. So I was thinking about reducing that list a bit dropping support for the oldest ones and replacing them with recent GCC/Clang from WSL (Windows Subsystem for Linux). My first idea is to drop anything older than 10 years, which means that the minimum will be MSVC 9.0 and GCC 4.3 (both released in 2008). I've reviewed some popular long support Linux distributions: -> RHEL 6 uses GCC 4.4. -> SUSE Linux Enterprise Server 11 Service Pack 4 (SP4) uses GCC 4.3 Microsoft no longer supports Visual 2008 (support ended on April 2018) but I can continue compiling and testing it at least for another year. Note that my libraries will continue support for -std=C++03, but I will not find workarounds or fixes for old GCC and MSVC versions. Thoughts, problems, comments? Best, Ion

6 9

[histogram] Formal review
by Bjorn Reese 01 Oct '18

01 Oct '18

Boost.Histogram contains useful and well-designed features, like excess (over/underflow) bins, and axis transforms to name a few. As this is a review, I am going to spent most time below on critical scrutiny. I. DESIGN --------- Iterators are const. This prevents us from bootstrapping the histogram with a prior distribution using STL algorithms like std::fill(), std::generate(), or std::sample(). The adaptive_storage does not work well with STL algorithms, because weight_counter is not an arithmetic type. See the Implementation section below for more detail. I therefore propose that the default storage policy is changed to something without weight_counter. The adaptive_storage has two responsibilities: data compaction and weights. Would it be possible to split this into two separate storage policies? I have no real use for arrival variance. I am not too fond of using operator() for insertion. The code looks like a function call with side-effect. I prefer an explicitly named member function. The axis::ouflow_type is oddly named. I suggest that this is renamed to something like axis::excess_type. II. IMPLEMENTATION ------------------ The implementation is generally of high quality. However, I did encounter the three problem areas listed below. (A) Integration with STL algorithms can be improved. Here are some examples: First, std::distance() does not work on a histogram with array_storage. This means that other STL algorithms, like std::any_of(), fails to compile. I solved this problem by copying the distance_to() function from the axis iterator to the histogram iterator. Second, std::max_element (and brethren) cannot be used on a histogram. Consider the following example: auto element = std::max_element(h.begin(), h.end()); Compilation fails for adaptive_storage because weight_counter has no less-than operator. Furthermore, compilation fails for array_storage because iterator_over<H>::operator= fails. It attempts to re-assign a reference, but accidentally triggers a copy-constructor instead. Letting the iterator store a pointer instead of a reference solves the problem. Apropos, iterator_over<H>::operator= does not return *this. Consider adding the -Werror=return-type compiler flag and a unit-test to that calls this operator. Third, std::inner_product fails to compile for adaptive_storage because weight_counter does not have a binary operator*. The inner product of two histograms is useful for calculating the cosine similarity, which can be used to compare two distributions. std::inner_product works for array_storage though. (B) Indexing and size use different types (int versus std::size_t.) I assume that this is because of the underflow bin, which is indexed by -1. I am not certain whether or not this is a real problem, but it does cause some oddities when stressed to the limit. For example, if we need a histogram that counts each unsigned int, then we get an "lower < upper" exception during construction: using range_type = unsigned int; auto h = make_static_histogram_with( array_storage<int>(), axis::integer<>(0, std::numeric_limits<range_type>::max())); It works if we reduce the end by 2, but then we are not collecting all values (unless we shift the range left by 1 and misuse the excess bins for the two missing values.) A possible solution could be to replace the -1 and N excess indices with an "enum struct excess { lower, upper }" and let operator[] et al use overloading on this enum. (C) Sometimes the compilation errors are nonsensical. For example: // Forgot to use make_static_histogram_with() auto h = make_static_histogram(array_storage<int>, axis::regular<>(10, 0, 1)); triggers an incomprehensible static_assert plus an error about a missing .shape() function. III. DOCUMENTATION ------------------ User guide is clear and pedagogical. I would like to see more examples that uses STL algorithms, such as calculating the CDF using std::partial_sum(), or calculating the cosine similarity of two histograms using std::inner_product(). Most examples use std::cout plus a comment to document the results of operations. Consider using assert() instead. Consider using a tabular layout similar to that of the C++ standard (or cppreference.com for that matter) on the Concepts page. Reference documentation is rather meager and shows implementation details. The documentation contains both a "Reference" and a "References" chapter which are completely different. Consider renaming the latter to something like "External references" , "Literature references", or "Bibliography". IV. MISC -------- I have spent around 15 hours on the review, mainly writing small examples that uses STL algorithms on Boost.Histogram. I am well-versed in the topic. I work with statistical distributions for real-time analysis of data, although I mainly dabble around in one dimension. I have written a library for online/streaming statistical algorithms. V. VERDICT ---------- While Boost.Histogram is a small niche library, it has a wide range of practical applications to warrant the inclusion into Boost. Boost.Histogram should be ACCEPTED into Boost, provided: 1. Reference documentation is finalized. I furthermore strongly recommend that the default storage policy is changed to something without weight_counter because of the various problems with STL algorithms. This recommendation is not a prerequisite for acceptance.

2 3

Median in Boost.Accumulators
by Lakshay Garg 30 Sep '18

30 Sep '18

Hello Boost Some time ago, I needed to compute the exact median for a stream of elements and after using Boost.Accumulators, realized that it only provides an approximation of the median and not the exact number. I rolled up my custom implementation of the algorithm and used it for my project. I wanted to check if people on this list might be interested in such an implementation for Boost.Accumulators in which case I can try to adapt my implementation and send a PR. Performance characteristics: For a stream of n numbers, the memory required is O(n). Median can be queried at any point of time in O(1) and adding all the elements costs O(nlog(n)) Lakshay

3 5

Will boost support DTLS / UDP?
by jupiter 29 Sep '18

29 Sep '18

It seems to me that Boost does not support DTLS so far, any plan and time line for boost to support DTLS?

2 1

CMake in Boost
by Robert Ramey 29 Sep '18

29 Sep '18

Many have expressed the desire that Boost support CMake. The Boost Board of Directors has emitted some sort of resolution to this effect - it's been a year. I would like to see progress in this direction. To this end I propose the following: a) Boost announce that a review of proposals to incorporate CMake into boost will be held in January 2019. This will follow customary Boost practices. b) Those who are willing and able to submit code/documentation and whatever else in necessary should do so before this date. I would anticipate at least two such submissions. As is the case with other reviews, I would not exist such submissions to be totally complete. But I would expect that they include enough for reviewers to test and practice with the proposed system. c) Prior to this discussions can be held on the list regarding the scope of such an effort. The review manager will distill these discussions to a statement of scope. This will be posted around 30 October 2018. I nominate myself (Robert Ramey) as review manager in this instance. Why would I do this? a) Boost needs this b) I've never been a review manager c) I'm a masochistic idiot. Robert Ramey

4 8

[test] How to execute shell commands
by Mike Dev 28 Sep '18

28 Sep '18

Does the boost unit test frame work provide a way to write a test that executes a couple of shell commands? Specifically, I want to write a test that compiles a cmake project: https://github.com/boostorg/vmd/pull/4 https://github.com/boostorg/preprocessor/pull/20 what I need to do for that is essentially (on Linux): - mkdir <build_dir> - cd <build_dir> - cmake <source_dir> - cmake --build . Of course I can write a cpp program that uses std::system to execute those commands but I was wondering if there was a more direct way to do it. Best Mike

5 7

contract work
by Ggh 28 Sep '18

28 Sep '18

Hi, Sorry to pollute but: Available for contract work, code samples here: http://www.multi.fi/~ghaga/bak1 Cheers Greg

2 1

stufff
by Ggh 28 Sep '18

28 Sep '18

I don't know what I am up to: http://www.multi.fi/~ghaga/bak1/ http://www.multi.fi/~ghaga/ Thank you, Greg

1 0

Re: [boost] [cmake] Pull request announcement
by Bjorn Reese 28 Sep '18

28 Sep '18

On 09/14/18 13:44, Mike Dev via Boost wrote: > This will not address > - Testing [...] > In short: all the difficult stuff is left out ;) > The goal is not to present a solution that can replace b2 but to have > a minimal starting point upon which individual library authors or the > community as a whole can make iterative improvements. If and when BCM > (or an alternative) is accepted into boost, individual libraries can > then easily switch to this full-fledged solution and of course any > author can create a more complete CMake solution for his library at > any time (as some already have). In my experience, we want to have both an integration and standalone CMake file. This split is necessary to avoid problems with multiple instances of enable_testing() when using one library from another. * The integration file builds only what is necessary for integration into other projects. This is similar to what you are proposing. * The standalone file builds everything including test and documentation. This reuses the integration file to build the library itself. If we place your proposed CMake file in the library root, and dependent libraries start using that location, then it becomes difficult to later have the standalone CMake file in the library root, which is the more natural choice. So we should be cautious about where we place these files.

22 91

Formal Review of Proposed Boost.Histogram Library Starts TODAY
by Mateusz Loskot 27 Sep '18

27 Sep '18

Dear Boost Community, The formal review of Hans Dembinski's Histogram library starts TODAY, the September 17th, and lasts until September 26th, unless an extension occurs. =========== What is it? =========== Histogram is a header-only C++11 library, provides multi-dimensional histogram template class for counting, statistics and data exploration. The histogram class interface has been carefully designed to make the library * offer simple and convenient default behaviour * easy to learn and safe to use * convenient to use for one- as well as multi-dimensional analysis * compatible with STL algorithms * dependant only on C++11 standard library and optionally on Boost The author followed the "Don't pay for what you don't use" principle. The histogram class is customisable through policy classes, but the default policies were carefully crafted so that most users do not need to customize anything. The default policies guarantee the histogram to be safe to use as a black box, memory efficient, and very fast, where safety is related to overflow prevention and large values capping. This guarantees is one of unique features of the library in comparison to other implementations. The histogram class comes in two variants, which share a common interface: * static variant is optimised at compile-time to provide maximum performance, at the cost of reduced runtime flexibility and potentially larger executables; * dynamic variant is a bit slower, but configurable at run-time. Both variants of the histogram class provide optional serialization support implemented with Boost.Serialization. The library itself is header-only and the tests as well as examples can be built using both, Boost.Build and CMake. There are no dependencies required other than C++11 compiler. Optional dependencies include the GNU Scientific Library (GSL) and the ROOT framework from CERN which are needed the corresponding speed test programs used for performance comparison. A note on history: The library was first announced to the Boost community in May, 2016 [1] and the author received extensive feedback. Then, after a year of work posted second request for comments in April, 2017 [2]. =================== Getting the library =================== Checkout the `master` branch from the library git repository: https://github.com/HDembinski/histogram/ NOTE: The author follows the library submission process [3]: the master branch remains frozen for the period of the formal review, modifications in response to feedback should go to `develop` branch and big items may be worked and discussed via opening an issue on GitHub. Documentation: http://hdembinski.github.io/histogram/doc/html/ Website: http://hdembinski.github.io/histogram/ ================ Writing a review ================ Please, follow the official Boost formal review procedure [4]. If you feel this is an interesting library, then please submit your review to the Boost developer list (preferably), or the review manager to mateusz (at) loskot (dot) net. Here are some questions you might want to answer in your review: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And finally, every review should answer this question: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. If needed, refer to the Boost Library Requirements and Guidelines [5]. Please, give constructive criticism! [1] https://lists.boost.org/Archives/boost/2016/05/229389.php [2] https://lists.boost.org/Archives/boost/2017/04/234410.php [3] https://www.boost.org/development/submissions.html#Review [4] https://www.boost.org/community/reviews.html [5] https://www.boost.org/development/requirements.html Mateusz Review Manager for the proposed Boost.Histogram -- Mateusz Loskot, http://mateusz.loskot.net

7 54

[GitHelp] release version of boost from GitHub?
by Kostiantyn Ponomarenko 26 Sep '18

26 Sep '18

Hi, guys. What is the right place for getting the last/or-any (released) version of boost? This page provides the last release as well as others: https://www.boost.org. But I've got the impression that after Boost moved to GitHub and became "modular", the releases can be downloaded right from the GitHub "releases" page. So it looks like it is not the case, and my assumptions is wrong because when I go to the "releases" page on GitHub (https://github.com/boostorg/boost/releases) and download a release (let's say "boost-1.68.0") I don't get any libs inside. Could you please help me to understand this situation. Is the only place to get a release of boost is https://www.boost.org, but not GitHub? Is GitHub used only for development, or getting the latest changes which are not released yet? --- Kostia Kyiv, Ukraine

3 3

Formal Review of Proposed Boost.Histogram Library - LAST DAY
by Mateusz Loskot 26 Sep '18

26 Sep '18

Dear Boost Community, According to the review schedule, the formal review of Hans Dembinski's Histogram library lasts until the end of TODAY. Please, anyone who is aiming to post a review, hurry up! If there are members who have planned to post a review and still wish to do it but require more time, please speak up now indicating how much time you'd need. [1] https://www.boost.org/community/review_schedule.html Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

Making Boost invisible
by John Maddock 25 Sep '18

25 Sep '18

Folks I have a bug report against Boost.Config that I don't know what (if anything) I should do about: https://github.com/boostorg/config/issues/243 The issue is this: lets say I build boost as static libraries with -fvisibilty=hidden because I want my application or shared library to *hide all boost symbols*. But there are some parts of boost which unconditionally make things visible - throw_exception is one particular culprit, but there are others, probably anything which uses BOOST_SYMBOL_VISIBLE in fact. Question: should we support this? If so how? The only thing I can think of is a user-defined macro which when set, disables symbol visibility. Thoughts? Thanks, John. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

7 9

Re: [boost] Formal Review of Proposed Boost.Histogram Library Starts TODAY
by Klemens David Morgenstern 25 Sep '18

25 Sep '18

- What is your evaluation of the design? The design is excellent, in that is geared towards readability and performance. - What is your evaluation of the implementation? It looks highly optimized with a focus on only being as cheap as possible on CPU. I.e. only pay for what you use. - What is your evaluation of the documentation? Detailed, good examples, I understood everything. - What is your evaluation of the potential usefulness of the library? It's not my domain, but for anyone interested in data analysis this seems super useful. I think there should be more libraries from that domain, even tough it's not my primary one. - Did you try to use the library? With what compiler? Did you have any problems? Yes, I did last year, when it was still in development, I used MinGW 5 and MSVC 2017. No problems. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I looked into the library in depth last year and gave the author my feedback on several implementation details. - Are you knowledgeable about the problem domain? Not in depth, but I know the basics. And finally, every review should answer this question: - Do you think the library should be accepted as a Boost library? Yes, definitely.

2 1

Interest in Unicode library for Boost?
by Zach Laine 23 Sep '18

23 Sep '18

I've been working on a Unicode library for submission to Boost, with an eye toward standardizing robust Unicode support for C++. It started as a better string library for namespace "std2", with minimal Unicode support. Though "std2" may never happen, those string types are still in there, and the library has grown to also include all the Unicode features most users will ever need. You can find the Github page here: https://github.com/tzlaine/text You can find the online docs here: https://tzlaine.github.io/text If you care about portable Unicode support, or even addressing the embarrassment of being the only major production language with next to no Unicode support, please have a look and provide feedback. I gave a talk about this at C++Now in May, though it's a bit out of date, as the library was not then finished. It's three hours, so, y'know, maybe skip it. For completeness' sake: https://www.youtube.com/watch?v=944GjKxwMBo&index=7&list=PL_AKIMJc4roVSbTTf… https://www.youtube.com/watch?v=GJ2xMAqCZL8&list=PL_AKIMJc4roVSbTTfHReQTl1d… Zach

8 16

Re: [boost] Median in Boost.Accumulators
by Lakshay Garg 23 Sep '18

23 Sep '18

On Sun, 23 Sep 2018 at 12:53, Zach Laine <whatwasthataddress(a)gmail.com> wrote: > > On Sun, Sep 23, 2018 at 2:45 PM Lakshay Garg <lakshayg373(a)gmail.com> wrote: >> >> On Sun, 23 Sep 2018 at 11:59, Zach Laine <whatwasthataddress(a)gmail.com> wrote: >> > Also, what if I don't actually call get() very often? >> >> If get() is not called very often, then I guess just using a plain vector and >> calling nth_element on it would be the best approach. >> >> > Is there any way to take advantage of make_heap()'s O(n) characteristics, >> > and avoid doing an O(n) push_heap() n times? I can't think of one offhand, >> > just curious. >> >> The complexity of push_heap is actually O(log(n)) and not O(n) > > [make.heap] says: > > Complexity: At most 3 * (last - first) comparisons. > Correct! complexity for make_heap is O(n) and complexity for push_heap is O(logn). https://en.cppreference.com/w/cpp/algorithm/make_heap https://en.cppreference.com/w/cpp/algorithm/push_heap

1 0

Re: [boost] Median in Boost.Accumulators
by Lakshay Garg 23 Sep '18

23 Sep '18

On Sun, 23 Sep 2018 at 11:59, Zach Laine <whatwasthataddress(a)gmail.com> wrote: > > On Sun, Sep 23, 2018 at 10:59 AM Lakshay Garg <lakshayg373(a)gmail.com> wrote: >> >> On Sun, 23 Sep 2018 at 08:39, Zach Laine via Boost >> <boost(a)lists.boost.org> wrote: >> > >> > Could you compare and contrast this with the standard library's way of >> > computing a median, std::nth_element()? Yout just give it N/2 for 'n', and >> > it computes the median. >> >> The reason for not using std::nth_element was because I wanted >> to be able to query the median at any point of the sequence very >> efficiently. Had I used std::nth_element, I would have needed O(n) >> time for obtaining the median. For a case where I need to compute >> median after every single element, this would have required O(n^2) >> time for a sequence of length n. Here is my implementation in case >> you would like to have a look: >> >> https://gist.github.com/lakshayg/d27f29b4634cbfea3fc48c21b7b608ef > > I missed that the first time, thanks. > > Your implementation does not seem to support a windowed working set > (one element at a time is added and the oldest one removed). Is that right? Yes, that is correct. This approach does not support a window. > Also, what if I don't actually call get() very often? If get() is not called very often, then I guess just using a plain vector and calling nth_element on it would be the best approach. > Is there any way to take advantage of make_heap()'s O(n) characteristics, > and avoid doing an O(n) push_heap() n times? I can't think of one offhand, > just curious. The complexity of push_heap is actually O(log(n)) and not O(n)

1 0

Re: [boost] Median in Boost.Accumulators
by Bjorn Reese 23 Sep '18

23 Sep '18

On 09/23/18 04:21, Lakshay Garg via Boost wrote: > I rolled up my custom implementation of the algorithm and > used it for my project. I wanted to check if people on > this list might be interested in such an implementation > for Boost.Accumulators in which case I can try to adapt my > implementation and send a PR. Boost.Accumulators does not seem to be actively maintained. > Performance characteristics: For a stream of n numbers, the > memory required is O(n). Median can be queried at any point > of time in O(1) and adding all the elements costs O(nlog(n)) Sounds like you keep two ordered lists (e.g. std::set) of equal size. Then the median is the first element in the second list.

2 1

Formal Review of Proposed Boost.Histogram Library is HALFWAY through
by Mateusz Loskot 22 Sep '18

22 Sep '18

Dear Boost Community, We've reach half-way through the formal review of Hans Dembinski's Histogram library. The review lasts until the end of September 26th. If you are interested in applications for mathematics, statistics graphics, image analysis, and such, or in the Histogram library itself, please consider reviewing the Histogram library by the end of September 26th. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

[filesystem] Library maintainers needed
by Beman Dawes 22 Sep '18

22 Sep '18

I'm retiring, so Boost.Filesystem needs one or more maintainers. This is a high complexity library, further complicated by (1) requiring both Windows and non-Windows implementation code and (2) needing a major upgrade for compatibility with the new standard library version shipped in C++17. Furthermore, there are constant Pull Requests and Issues that arise, and these almost invariably take a lot of time for the maintainer to process. My personal opinion is that Boost should deprecate the Boost library in favor of the standard library implementations, and do only minimal maintenance for several years until most users have migrated to C++17 or later. But that's up to the new maintainers to decide. Thanks, --Beman

3 2

[endian] Library maintainer needed
by Beman Dawes 22 Sep '18

22 Sep '18

I'm retiring, so Boost.Endian needs a maintainer. This is a low/medium complexity library that requires only minor effort to maintain. --Beman

2 1

[timer] Library maintainer needed
by Beman Dawes 22 Sep '18

22 Sep '18

I'm retiring, so Boost.Timer needs a maintainer. This is a simple low complexity library, and requires little effort to effort to maintain. --Beman

1 0

[build][testing] Tests naming in Jamfile
by Mateusz Loskot 21 Sep '18

21 Sep '18

Hi, I'm updating Jamfile-s of Boost.GIL and it made me wondering: For example: test-suite "boost-gil-test" : [ run promote_integral.cpp ] ; Apart from replacing the deprecated test-suite with alias, I wonder what is the recommended policy of naming the test suites, are there any rules? For example, should it be more or less hierarchical boost-{lib}-{testname} {lib}-{testname} {testname} or the name is completely local to/internal in a library and library maintainers are free to name as they desire? I could not find anything in the development guidelines and the testing policy docs. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net p.s. Originally posted to boost-testing incorrectly https://lists.boost.org/boost-testing/2018/09/8446.php

2 2

[system] A non-allocating message() overload
by Peter Dimov 20 Sep '18

20 Sep '18

One of the objections against <system_error> is that message() needs to allocate memory, because it returns an std::string. This is true even for user-defined categories that can implement it without allocating, with a static message table. To address this, I'm thinking of adding the following overload to boost::system::error_category (with the intent of proposing it for std::error_category): virtual char const* message( int ev, char* buffer, size_t len ) noexcept; This is modeled after the glibc-specific version of strerror_r (and in fact has the exact same signature and behavior). If the implementation has a static character literal corresponding to `ev`, it returns it directly. If not, it composes an error message into the provided buffer, then returns `buffer`. Comments?

3 7

HoF Problems with Boost 1.68 / LLVM-Clang / Windows
by Adam Hartshorne 20 Sep '18

20 Sep '18

The following two bits of code compile ok with MSVC, but using LLVM/Clang produces the following errors. Using the code in print.cpp BOOST_HOF_STATIC_FUNCTION(simple_print) = fix(first_of( BOOST_HOF_LIFT(print_with_cout), BOOST_HOF_LIFT(print_with_range), BOOST_HOF_LIFT(print_with_tuple) )); produces the following error 1>./boost_hof_functions.h(45): error : templates cannot be declared inside of a local class 1>C:\boost_1_68_0\boost/hof/lift.hpp(90): note: expanded from macro 'BOOST_HOF_LIFT' 1>C:\boost_1_68_0\boost/hof/lift.hpp(105): note: expanded from macro 'BOOST_HOF_LIFT_CLASS' And BOOST_HOF_STATIC_LAMBDA_FUNCTION(print) = boost::hof::proj(simple_print); produces >./boost_hof_functions.h(51): error : non-const lvalue reference to type 'reveal_adaptor<...>' cannot bind to a temporary of type 'reveal_adaptor<...>' 1>C:\boost_1_68_0\boost/hof/lambda.hpp(241): note: expanded from macro 'BOOST_HOF_STATIC_LAMBDA_FUNCTION'] There are nearly identical errors with functions from in.cpp.

2 1

"is-assignable" compile error using Boost 1.68 / LLVM-Clang / Windows
by Adam Hartshorne 20 Sep '18

20 Sep '18

I receive the following build error when switching to LLVM toolset in VS2017 to build code using Boost 1.68. The code builds fine with MSVC compiler. 1>C:\boost_1_68_0\boost/type_traits/has_trivial_move_assign.hpp(49): error : no template named 'is_assignable'; did you mean 'std::is_assignable'? 1>C:\boost_1_68_0\boost/type_traits/intrinsics.hpp(233): note: expanded from macro 'BOOST_HAS_TRIVIAL_MOVE_ASSIGN'

4 6

Unexpected behavior in reverse lookup (asio resolver)
by LC 19 Sep '18

19 Sep '18

When performing a reverse lookup of an address: *r->async_resolve( boost::asio::ip::tcp::resolver::endpoint_type( adr, 80 ) ...* the address itself is returned (as string), when the name of the host cannot be found. I would expect an error/exception, telling me this instead. Consider the following (custom class which does both): *Resolver::resolve< ResolverClass >( &rc, "www.yahoo.com", 1 ); Resolver::resolve< ResolverClass >( &rc, "8.8.8.8", 2 ); Resolver::resolve< ResolverClass >( &rc, "none.exist.end", 3 ); Resolver::resolve< ResolverClass >( &rc, "2.18.77.109", 4 ); Resolver::resolve< ResolverClass >( &rc, "198.252.206.16", 5 ); Resolver::resolve< ResolverClass >( &rc, "234.255.173.123", 6 );* And the result: *1: hostname: www.yahoo.com, address: 87.248.98.7, error: 1: hostname: www.yahoo.com, address: 87.248.98.8, error: 2: hostname: google-public-dns-a.google.com, address: 8.8.8.8, error: 3: hostname: , address: 0.0.0.0, error: Host not found (authoritative) 4: hostname: a2-18-77-109.deploy.static.akamaitechnologies.com, address: 2.18.77.109, error: 5: hostname: stackoverflow.com, address: 198.252.206.16, error: 6: hostname: 234.255.173.123, address: 234.255.173.123, error:* 2 is looking up of "8.8.8.8", which of course can be found and returns the google.com entry. Likewise, 4 and 5 can be found and return the correct result. *Nr. 6, however, is a non-existent ip-address. As you can see, instead of an error, the address itself is returned when calling "endpoint_iterator->host_name();".* This is unexpected and (I think) undocumented. It can be easily detected by testing if host_name returns an address, but this would require another (test) conversion; as a result you'd end up with forth&back conversions. Wouldn't it be better, if the reverse lookup returned an error/exception, if the name of the host cannot be found? This would be more consistent with the "Host not found (authoritative)" error in example 3. -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

3 4

[cmake] Pull request announcement
by Mike Dev 18 Sep '18

18 Sep '18

Dear all, unless I'm encountering an overwhelming resistance to this idea here on the ml, I intend to create a batch of PRs that introduce minimal cmake support to a large subset of boost libraries (maybe even all). It appears that cmake efforts have yet again stalled. Last I heard was that everyone is waiting for BCM and the author of that library still tries to find a review manager. As we probably can't expect a full-fledged, boost-wide solution in the near future I'm trying it with a low-effort approach that will establish the minimal framework needed such that each library can be (where necessary) build with cmake and specify it's dependencies on other libraries (the latter being the really important part). >From that starting point a more holistic solution can then be developed step by step and (in most cases) library by library. The only fundamental thing that needs to be decided by the community is a canonical naming scheme for the cmake targets that should be used by other libraries in their `target_link_libraries` call. For that I suggest that each library should provide an alias target called Boost::<library_name> (e.g. Boost::program_options) This also follows the naming scheme provided by cmake itself when using boost libraries that are installed on the system. Now about what I'm specifically going to put into the PRs: - I'll propose a trivial, top-level cmake file be added to the boost super project that doesn't do anything but look for CMakeLists.txt files in the root folder of each library and calls that file if present - Individual libraries get a simple CMakeLists.txt file that will - create an appropriate build target - INTERFACE library for header-only - STATIC for regular libraries - create an alias named Boost::<library_name> - build the library if necessary - specifying the minimum required c++ version - specify the local include directory (iirc that will always be "include") - specify all required dependencies This will not address - Testing - Installation - Creation of shared libraries - Creation of documentation - Special provisions for IDE integration In short: all the difficult stuff is left out ;) The goal is not to present a solution that can replace b2 but to have a minimal starting point upon which individual library authors or the community as a whole can make iterative improvements. If and when BCM (or an alternative) is accepted into boost, individual libraries can then easily switch to this full-fledged solution and of course any author can create a more complete CMake solution for his library at any time (as some already have). Finally, please don't nick-pick this to death. I'd like to have a more complete solution too, but it isn't coming, so let's do the minimum we can and go on from there. Note that the advantage of such a minimal solution is also that there are very few design decisions to make that may later turn out to be wrong and then create a maintenance burden. The only things that are visible on an interface level (and thus should remain reasonable stable) are: - The alias name Boost::<library_name> - How the public dependencies are specified: target_link_libraries( boost_ foo PUBLIC Boost::config Boost::core Boost::bar ) - The position of the CMakeLists.txt file in the library root folder All of this is long established best practice. Anything else can gradually be built on top of that. Best Michael

15 38

[config] does BOOST_ATTRIBUTE_UNUSED defined implies __attribute__((used)) exists ?
by Raffi Enficiaud 17 Sep '18

17 Sep '18

Hi, I have a problem with symbol visibility in boost.test: https://github.com/boostorg/boost/pull/190 I am wondering if __attribute__((used)) is a portable way to flag a static const ref as being used, or there are variations (__attribute__((used)) vs __attribute__((__used__))). I am also wondering if __attribute__((used)) can be considered as available if BOOST_ATTRIBUTE_UNUSED is defined. Would it make sense to have an BOOST_ATTRIBUTE_USED in boost.config? Thanks, Raffi

2 1

[system] Do you use the deprecated features or cygwin/linux/windows_error.hpp?
by Peter Dimov 17 Sep '18

17 Sep '18

I'd like to query the Boost community as to whether certain legacy features of Boost.System are in use; namely, (1) everything guarded by BOOST_SYSTEM_ENABLE_DEPRECATED and (2) the cygwin_error.hpp, linux_error.hpp, or windows_error.hpp headers. Does anyone use these, and for what purpose? I'm thinking of dropping the deprecated features. In addition, does anyone use boost::throws()? I'm thinking of at least discouraging its use in the documentation, if not deprecating it outright.

2 1

CMake and the Boost Steering Committee
by Edward Diener 16 Sep '18

16 Sep '18

I think it is a huge waste of time for anyone to discuss or implement a CMake solution for Boost until the Boost Steering Committee actually gets involves and defines what "Boost using CMake" actually means and gives the specifics as to what this actually entails. Otherwise nearly everything said about Boost and CMake, although well-intentioned, is just a lot of hot air and we are going absolutely nowhere trying to make any progress in this so-called direction. The Boost Steering Committee is largely at fault for saying that Boost would be using CMake, without defining what this actually means. Once again, as in our discussion about Boost dropping support for C++03, we are all wasting our time because the meaning of some language having been used is not clear and way too general to reach any meaningful conclusions. But in this case the only people who can really define what Boost using CMake actually means is the Boost Steering Committee, or someone representing the Boost Steering Committee on this mailing list, who can clarify what Boost using CMake is actually about, since it was the Boost Steering Committee who made the decision in the first place. If it is not the case that the Boost Steering Committee defines what Boost using CMake actually is supposed to mean but rather it is up to those on this mailing list to decide the issue, I would argue that Boost should focus on the simplest solution first, making Boost libraries, whether header-only or not, available for use in end-user CMake scripts in such a way that it will be easy to add this functionality for the 130 or so individual Boost libraries with the least amount of effort or work involved for each library, without arguing unduly about more complicated or more purist solutions. In other words lets start with the easiest, most practical solution, because I assure you when the smoke has cleared, 99% of those people involved in the discussion will not want to do the practical work of actual adding necessary CMake scripts to any of the 130 or so libraries involved, and even the maintainers of those libraries will not want to spend much time implementing some complicated CMake solution for their library. But I still think that without a specific definition of what Boost using CMake actually entails from the steering committee we are just wasting time and breath and to no good purpose.

1 0

How do I test more configurations locally
by Joshua Marshall 14 Sep '18

14 Sep '18

Hello all, How do I test more configurations on my local systems rather than relying on TravisCI and AppVeyor? I've been working on fixing up BGL to pass basic TravisCI and AppVeyor tests, but it seems I have to be particularly reliant on those online tests. I'd like to have more of that done on my local system. There is probably a way to do that, but I don't know what it is.

3 3

REMINDER: Formal Review of Histogram by Hans Dembinski
by Mateusz Loskot 14 Sep '18

14 Sep '18

Dear All, (NOTE: This is not start the review announcement yet) I'd just like to *remind* you all that the review of the Histogram library developed by Hans Dembinski is going to happen according to the schedule [1], from September 17, 2018 to Septenber 26, 2018. I will be sending the official START announcement this weekend. [1] https://www.boost.org/community/review_schedule.html Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

[outcome] Change semantics on UB from peer review agreed semantics?
by Niall Douglas 14 Sep '18

14 Sep '18

Dear Boost, At https://github.com/ned14/outcome/issues/150, Andrzej has raised his desire to change Outcome's semantics on UB from what the two peer reviews here agreed to previously. As this would be a major change to interface different to what the consensus here agreed to, I am asking boost-dev to weigh in with its opinion. Status: ------- Outcome has been finished, apart from docs, since April (http://boost.2283326.n4.nabble.com/outcome-v2-1-progress-report-td4702900.h…) for the Boost and standalone variants, and since July for the experimental P1028 edition. The documentation has not been touched since the February review, but will be tackled when my current work contract ends this November, and I regain free time. Preamble: --------- Outcome has the notion of programmable "default actions" which occur when the user does something like call `.value()` on a `result<T, E>` which has an error. Let's call this "value-on-valueless". Outcome, as was approved here, has the following selector on `result<T, E>` in the Boost edition: ``` template <class T, class EC, class E> using default_policy = std::conditional_t< std::is_void<EC>::value && std::is_void<E>::value, terminate, std::conditional_t< trait::has_error_code_v<EC>, error_code_throw_as_system_error<T, EC, E>, std::conditional_t< trait::has_exception_ptr_v<EC> || trait::has_exception_ptr_v<E>, exception_ptr_rethrow<T, EC, E>, all_narrow >>>; template <class R, class S = boost::system::error_code, class NoValuePolicy = policy::default_policy<R, S, void>> using boost_result = basic_result<R, S, NoValuePolicy>; template <class R, class S = boost::system::error_code, class NoValuePolicy = policy::default_policy<R, S, void>> using result = boost_result<R, S, NoValuePolicy>; ``` So, if result's `E` is: - `void`, value-on-valueless calls `std::terminate()`. - contains an error code, value-on-valueless throws `system_error()`. - otherwise is hard undefined behaviour i.e. we tell the compiler that value-on-valueless will never happen, and the compiler doesn't even compile code for it to happen. The documentation, as was approved here, made it very clear that hard UB is the default for custom defined `E` types. See https://ned14.github.io/outcome/tutorial/default-actions/happens1/. A nice segfault usually emerges. For the standalone edition, judging from user feedback and bug reports, this hard UB behaviour is the most common intentional configuration for Outcome users. I have not received any complaints about this choice, if anything a majority has been choosing Outcome precisely *because* of this choice. Andrzej's request ----------------- Andrzej points out in https://github.com/ned14/outcome/issues/150 that it's too easy to get surprised by a small source change which causes the error code trait to no longer match the `E` type, thus flipping the code base from throwing `system_error` into hard UB unexpectedly and without warning. He wishes to change the default to failure to compile i.e. if result's `E` is: - `void`, value-on-valueless calls `std::terminate()`. - contains an error code, value-on-valueless throws `system_error()`. - otherwise a failure to compile with useful diagnostic. Users can, of course, manually specify a `NoValuePolicy` of `all_narrow` if they wish hard UB on value-on-valueless. It would be a non-trivial change from what peer review (twice) agreed, as the default would have substantially changed. What is boost-dev's opinion on this proposed change in semantics? Thanks, Niall

10 32

list.boost.org
by David Bellot 09 Sep '18

09 Sep '18

Hi, I'm looking for the person in charge of lists.boost.org, the mailing list server. We're having an issue on one of the mailing list (ublas). Cheers, David

3 2

[ublas] How to merge a PR?
by Frédéric 09 Sep '18

09 Sep '18

Hi, I submitted a PR 1 month ago. Something rather trivial. How can it be merge? https://github.com/boostorg/ublas/pull/56 Thanks, F

2 1

Re: [boost] list.boost.org
by Bjorn Reese 09 Sep '18

09 Sep '18

On 09/09/18 00:13, David Bellot via Boost wrote: > I'm looking for the person in charge of lists.boost.org, the mailing list > server. We're having an issue on one of the mailing list (ublas). https://lists.boost.org/Archives/boost/2017/02/232710.php

1 0

[all] Request for out of the box visibility support
by Antony Polukhin 09 Sep '18

09 Sep '18

I'd like to draw attention to a problem with Boost binaries for Linux. There's an awesome -fvisibility=hidden flag for Linux compilers that improves load times, performance, size of binaries and reduces the chance of symbol collisions. More info at https://gcc.gnu.org/wiki/Visibility . Unfortunately, most of the Boost libraries do not set it by default: - atomic - chrono - container - context - contract - coroutine - date_time - exception - fiber - filesystem - graph - graph_parallel - iostreams - locale - mpi - program_options - python - random - regex - signals - system - test - thread - timer - type_erasure - wave Moreover minority of the above libraries just do not work with the flag. Users just can not run ./b2 cxxflags="-fvisibility=hidden" because there's a chance that some library could stop linking. Actually things are even more ugly. Linux distributions usually do not tune the build flags for each package so at least Debian based distributions build Boost with default flags. Users get suboptimal builds. If you're a maintainer of one of the above libraries *please do* the following steps: * Make sure that all the public symbols are accordingly marked with appropriate BOOST_SYMBOL_* macro. Instruction is available here: https://www.boost.org/doc/libs/1_68_0/libs/config/doc/html/boost_config/boo… * Turn on the visibility=hidden by default: * by adding <target-os>linux:<cxxflags>"-fvisibility=hidden" to the Jamfile if you do not care much for antique compilers (Example https://github.com/boostorg/stacktrace/blob/819f2b1c861dec7530372a990ecabab… ) * by using a more advanced technique for detecting the flag availability (For example see https://github.com/boostorg/math/blob/develop/build/Jamfile.v2#L20 or https://github.com/boostorg/log/blob/develop/build/Jamfile.v2#L24 ) P.S.: I would appreciate any comments or updates on the feature request. P.P.S.: Log, Math, Serialization (and Stacktrace) libraries already use that flag by default. Many thanks! -- Best regards, Antony Polukhin

10 33

[range] #11202: boost.sort header conflicts with boost.range header
by Steven Ross 07 Sep '18

07 Sep '18

https://svn.boost.org/trac10/ticket/11202 has been sitting for years. The "using range::sort" causing the namespace pollution needs to be deleted, and then everything depending on that inside boost needs to be fixed. This will break people dependent on the namespace pollution, but that's the only way to clean it up. Is anyone willing to take on this cleanup? Is there a good way to identify cross-library dependency breakages in situations like this so they can be fixed?

10 20

Trac
by Robert Ramey 07 Sep '18

07 Sep '18

Could we agree to stop using the Trac system? The github issues/pr system is much more functional. I propose we close the trac system to new issues - be of course leave it available for reference. Robert Ramey

21 57

Guidelines on copyright notice maintenance
by Mateusz Loskot 06 Sep '18

06 Sep '18

Hi, The license guidelines [1] include instructions on "How should Boost programmers apply the license to source and header files?" Unless I've missed it, there seem to be lack of guidelines about how to maintain (existing) copyright notices. I don't aim to resurrect the old lengthy thread from Sept 2015 on validity of copyright notices. In that thread, however, some guidelines or conventions were expressed: [2] "because copyright is only claimed for changes meeting a certain threshold of originality" [3] "It's up to those people to add a line if they so decide. Copyright only covers expressions of creativity." Those suggests, there seem to be common understanding on if/how/when it is recommended or even necessary to update copyright notice in a source file of a Boost library. Wouldn't it be helpful to captured those as guidelines in the BSL FAQ. Would there be someone knowledgeable about it and willing to make the update or at least explain it here? (I will make it into HTML and PR to boostorg/website) I understand David and Beman, primary authors of the page [1], may no longer be available. [1] https://www.boost.org/users/license.html [2] https://lists.boost.org/Archives/boost/2015/09/225565.php [3] https://lists.boost.org/Archives/boost/2015/09/225570.php Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 2

[ublas] Supporting DNNs with Tensors/Multidimensional Arrays
by Cem Bassoy 06 Sep '18

06 Sep '18

Gsoc <https://summerofcode.withgoogle.com/organizations/4507228564881408/> 2018 just ended one week ago and we had many successefully completed student projects <https://github.com/BoostGSoC18>. I was responsible for adding tensor support to Boost.uBLAS for primarily supporting multilinear algebra operations in the field of numerics. The wiki description along with the implementation can be found here <https://github.com/BoostGSoC18/tensor>. Similar to Boost.multi_array <https://www.boost.org/doc/libs/1_68_0/libs/multi_array/doc/index.html> the runtime-reshapable tensor data structure is parametrized in terms of number of dimensions (rank/order), dimension extents, data type, layout (first- and last-order) and storage type. The first two are runtime-variable. I am also about to add subtensor (view/handle of a tensor) along with multidimensional iterators for convenient algorithm implementation. It is yet not as flexible as GSL's multi_span <https://github.com/Microsoft/GSL/blob/master/include/gsl/multi_span>: does not yet support static rank and dimensions. However, basic generic tensor operations (contraction/transposition/reshaping/...), including a nice syntax for Einstein's summation convention with placeholders, using C++17 features are provided. The operations are evaluated using expression templates (not smart yet). Similar to the tensor <https://eigen.tuxfamily.org/dox/unsupported/group__CXX11__Tensor__Module.ht…> framework of Eigen, that is used by tensor flow <https://github.com/tensorflow/tensorflow>, the tensor data structure in Boost.uBlas could be taken for implementing deep neural networks or higher-order statistics I think. I am not sure if the C++ community would appreciate if Boost has some form of basic operations for building *deep neural networks* (DNNs). I would like to ask 1. if it make sense for boost to support basic operations for DNNs? 2. what are the obligatory, necessary basic operations for creating DNN building blocks? 3. if there are any additional data structure parameters that needs to be added for (efficiently) supporting DNNs? Best, Cem

3 5

Schedule update request
by Antony Polukhin 06 Sep '18

06 Sep '18

Schedule at https://www.boost.org/development/index.html does not show next release dates and close of merge window. Please update it. Thanks in advance!

1 0

Assistance debugging compile time isomorphism failure to get PR #114 working
by Joshua Marshall 05 Sep '18

05 Sep '18

Hello all, Since Saturday I've been banging my head against this one. Over at https://github.com/anadon/graph/tree/isomorph-fix I've been trying to fix some of the newly enables travisCI failures. I'm getting a persistent type mismatch that may not be resolvable sanely, but I want to get another set of eyes before I just the gun and start suggesting ripping out tests.

1 0

Deprecation of detail endian macros.
by Rene Rivera 03 Sep '18

03 Sep '18

This is a general announcement that I'm deprecating the following that is part of Predef: Header: boost/detail/endian.hpp Macros: BOOST_BIG_ENDIAN, BOOST_LITTLE_ENDIAN, BOOST_PDP_ENDIAN, and BOOST_BYTE_ORDER You can use the equivalents from Predef < https://www.boost.org/doc/libs/1_68_0/doc/html/predef/reference.html#predef…> as follow: BOOST_BIG_ENDIAN == BOOST_ENDIAN_BIG_BYTE BOOST_LITTLE_ENDIAN == BOOST_ENDIAN_LITTLE_BYTE BOOST_PDP_ENDIAN == BOOST_ENDIAN_LITTLE_WORD There is no equivalent for BOOST_BYTE_ORDER. But there are no uses in Boost as far as I could tell. In the develop branch of Predef I've added a deprecation message indicating as such. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

2 1

pending vs detail headers
by James E. King III 03 Sep '18

03 Sep '18

Is there any general guidance for moving headers out of boost/pending? Do we really need to include a forwarding stub for these? I'd like to consider headers in boost/pending as "not final" and therefore we should be able to move headers out of there without leaving a forwarding stub. Example: https://github.com/boostorg/dynamic_bitset/pull/24 - Jim

5 4

No Viable function warning
by randydom 03 Sep '18

03 Sep '18

Hello i've the bellow function : __declspec(dllexport) int TrySendData(_isocket * isocket,char * ibuff,int ilen) { boost::system::error_code ignored_error; boost::asio::write(isocket->socket(), boost::asio::buffer(ibuff,ilen), boost::asio::transfer_all(), ignored_error); if(ignored_error) return 0; return 1; } I get a *No Viable function* warning , can someone tells me why or helps me in fixing this warning . Thank you . -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

2 1

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

[vcpkg] Support non-Windows build. #4169
by degski 02 Sep '18

02 Sep '18

FYI: https://github.com/Microsoft/vcpkg/pull/4169#issuecomment-417867673 degki -- *“If something cannot go on forever, it will stop" - Herbert Stein* *“No, it isn’t truth. Truth isn’t truth" - Rudolph W. L. Giuliani*

1 0

[integer] CMT assume responsibility for Boost.Integer?
by James E. King III 01 Sep '18

01 Sep '18

The maintainer of Boost.Integer has no commits since 2008, and I was unable to get a hold of him by email (waited 10 days for a reply). I suggest we transfer responsibility of this repository to the CMT. - Jim

3 3

Gsoc 2019
by Shubham Verma 01 Sep '18

01 Sep '18

Hey I'm new, but I'd like to contribute to your organisation, can someone please guide me along?

5 4

Let's stop distributing binaries
by Robert Ramey 31 Aug '18

31 Aug '18

The fact is that users of boost use compilers with differing levels of C++ standard conformance. This creates a number of problems including (but probably not limited to) a) Using libraries built with different levels of C++ conformance may create ABI issues. b) it creates a discussion about "dropping C++03 support". Actually it creates a discussion about that the above actually means. c) It's motivated a suggestion that all libraries move to header only. This is not great idea - but I won't address that here. I believe all these issues - and more - would disappear if we just stopped distributing binaries. Each user would be building his own boost version with (presumably) the same compiler. Since C++03 compatible libraries are C++?? compatible, each library author can maintain the level of backward compatibility that he wishes. But if we're not going to distribute binaries, then users might as well just clone the latest "certified - good - tagged" version in the master branch from the github repo. That is, let's just stop or truncate the whole release circus. Replace with an occasional "certification/versioning procedure" which would make available a "squashed" master suitable for efficient cloning. This would make everyone's life easier. Robert Ramey

19 63

A possible date for dropping c++03 support
by Mike Dev 31 Aug '18

31 Aug '18

Sorry for all the bad line-breaks in my previous message. I don't have access to a properly configured email client right now. This should be easier to read: ====== Original Message ============== Please, let's not derail the discussion just after some consensus has emerged and just before it actually produces actionable items. Let's not make the better the enemy of the good here. I made the suggestion to commonly drop c++03 support in the hope that it would actually lead to some code simplifications and reduced coupling between the boost libraries - even if only in their implementation (if someone wanted to do a real c++14 reboot of their library, no one is/was stopping them anyway). >From the survey, I'd say interest in actually applying c++11 features in libraries that a currently supporting 03 is already relatively low, but big enough that I believe this will actually lead to some changes other than just changing the default test settings. That is with a standard almost universally supported by compilers in use today. Even though the move from 11 to 14 is much less dramatic, c++14 support is less wide spread and outside of the big three, there are many compilers where even the most recent version doesn't support c++14, so I just don't see people that are currently maintaining c++03 support in their libraries suddenly starting to use c++14. All this doesn't preclude a discussion about if and when to move to c++14 or a general policy about LTS versions and the like, but please keep it separate unless you are really, really confident it will lead to something actionable earlier than what is currently proposed. I have lots of Ideas, how boost could be reformed and/or modernized but in the end it comes down to convince the individual library maintainers to actually do something. I think the current proposal will at least spark some action. Let the announcement to move to cmake be a warning sign about realistic expectations about the evolution of boost. Maybe I'm aiming too low, but again, if you want more, please open a separate thread and most likely, whatever you come up with there will not be mutually exclusive with what is proposed here. Regarding the test settings: If c++11 is supposed to be the lowest official supported version then that is what should be tested Anything else doesn't make sense (you can't claim to support c++11 if you don't test if it actually works there). In any case, as was mentioned before, for the announcement itself we don't need give any specifics about something that is going to happen 1-1,5 years from now. How about something like " c++03 mode/compilation will no longer be tested / part off the general test/suit"? Best Mike

1 0

A possible date for dropping c++03 support
by Mike Dev 31 Aug '18

31 Aug '18

Please, let's not derail the discussion just after some consensus has emerged and just before it actually produces actionable items. Let's not make the better the enemy of the good here. I made the suggestion to commonly drop c++03 support in the hope that it would actually lead to some code simplifications and reduced coupling between the boost libraries - even if only in their implementation (if someone wanted to do a real c++14 reboot of their library, no one is/was stopping them anyway). >From the survey, Id' say interest in actually applying c++11 features in libraries that a currently supporting 03 is already relatively low, but big enough that I believe this will actually lead to some changes other than just changing the default test settings. That is with a standard almost universally supported by compilers in use today. Even though the move from 11 to 14 is much less dramatic, c++14 support is less wide spread and outside of the big three, there are many compilers where even the most recent version doesn't support c++14, so I just don't see people that are currently maintaining c++03 support in their libraries suddenly starting to use c++14. All this doesn't preclude a discussion about if and when to move to c++14 or a general policy about LTS versions and the like, but please keep it separate unless you are really, really confident it will lead to something actionable earlier than what is currently proposed. I have lots of Ideas, how boost could be reformed and/or modernized but in the end it comes down to convince the individual library maintainers to actually do something. I think the current proposal will at least spark some action. Let announcement to move to cmake be a warning sign about realistic expectations about the evolution of boost. Maybe I'm aiming too low, but again, if you want more, please open a separate thread and most likely, whatever you come up with there will not be mutually exclusive with what is proposed here. Regarding the test settings: If c++11 is supposed to be the lowest official supported version then that is what should be tested Anything else doesn't make sense (you can't claim to support c++11 if you don't test if it actually works there). In any case, as was mentioned before, for announcement itself we don't need give any specifics about something that is going to happen 1-1,5 years from now. How about something like " c++03 mode/compilation will no longer be tested / part off the general test/suit"? Best Michael

1 0

A possible date for dropping c++03 support
by Mike Dev 30 Aug '18

30 Aug '18

>From the discussion about abi compatibility when the Boost.System library is compiled e.g. in c++03 mode and then included in ac++11 project or vice versa (https://groups.google.com/forum/#!topic/boost-developers-archive/EWG5NVOZo_ g) > > When can we drop C++03 support? :D This will probably be ignored or shouted down, but maybe someone just needs to make a concrete suggestion about which people can discuss and vote so I'm giving it a shot: What about the first or second release in 2020 ? By then, all major toolchains have had solid c++11 support for at least 5 years ( I think, msvc was the last one with VS2015) and at least partial support for 7+ years (gcc 4.8, msvc 2013, clang 3.3). Also, most likely c++20 will be released in that year, which means that c++03 compatible libraries would have to support 5 different (and partial incompatible) language versions by then (not to mention ABI-compatibility considerations between different versions). That should also be enough time to ensure that the last c++03 release (late 2019) is really solid (for projects that still can't upgrade to c++11) and ideally there could be a few more bugfix-releases afterwards as is often done by other software projects. And before someone starts to raise straw mans: That of course wouldn't mean that a particular library *must* no longer compile in 03 mode, but one can no longer rely on the boost-internal dependencies remaining c++03 compatible. Best Mike

23 104

[ptr_container] associative container insert takes reference instead of const reference as key ?
by comic fans 30 Aug '18

30 Aug '18

Hello , I've found that ptr_unordered_map.insert has following signature (from code and latest doc) std::pair<iterator,bool> insert( key_type& k, T* x ); that forbids calls like ptr_unordered_map.insert( myobj->id(), myobj) ,I wonder if this is by design , or some other reason ? why other overload takes const key_type& k as key type? and insert always call insert_impl which have const reference as key type ? any help would be appreciated.

2 5

c++03 library survey
by Mike Dev 29 Aug '18

29 Aug '18

Hello everyone, this is closely related to the thread about "A possible date for dropping c++03 support" (https://groups.google.com/forum/#!topic/boost-developers-archive/i4UM-GfNu8w) but this is NOT meant as a vote on the suggestion, and I'd ask you to keep discussions to that thread. For the actually important part, please scroll down to the double line (===) For reference however, my suggestion was that c++03 support is officially dropped somewhere around early 2020 across all of boost. Which would mean, that from then onwards any library author could start to unconditionally use c++11 features in his library without prior announcement or transition period, even if other boost libraries that currently support c++03 have a dependency on it. (Again, if you have questions or comments about this, please answer on the other thread) Somewhat late, I realized I first should have asked if / how much actual interest there is from the side of the library maintainers in the first place, because whatever the majority of the people on the ML thinks, it obviously won't have any effect if the actually affected people don't have any interest in using c++11 in the first place. Full disclosure: I'm not a boost contributor myself (at least nothing significant) but as a user, I have an interest in boost libraries becoming simpler, less entangled with each other and providing less types that are redundant in c++11 and later. You could call that more lightweight but that is a different topic. So, to get some idea if there is any interest in this topic, I'd ask each maintainer that is currently maintaining a c++03 compatible library to answer the following questions: =======Please quote from here ====================================== - Which library/ies are you maintaining? (I assume this isn't some sort of private information - otherwise ignore the question) - Would you like to unconditionally use c++11 features if you would not have to worry about this breaking boost internal users? - Would you like to unconditionally use c++11 features if you would not have to worry about this breaking any users? - Would you deprecate your library completely if there were no boost-internal users and your current dependencies required c++11 (e.g. because your library has been merged into the c++11 standard library anyway) - Are you yourself using any boost library (in an up-to-date version) in a c++03, non-boost project? - Do you have any Idea if the latest versions of your library is used by any important/significant number of c++02 projects? [It is only important if *you* consider those projects important and or the number significant] =======Please quote till here ====================================== Note: When I'm talking about breaking users I mean breaking due to requiring c++11 compiler, not because you completely rewrite the API based on new c++11 idoms - that would probably better be done in a completely new library. Best regards and thank you for your time Mike

15 32

Re: [boost] A possible date for dropping c++03 support
by Glen Fernandes 29 Aug '18

29 Aug '18

Edward Diener wrote: > Other than not removing useful Boost libraries which support c++03 as > well as all subsequent C++ standard levels, and not telling people that > they can not use such libraries in c++03 mode if they actually want to > do so, I am perfectly willing to let others, including yourself, decide > the best way in which support for c++03 in Boost is reduced. My argument > has always been that putting a generalized statement on the website, > without explaining what it actually entails as far as using Boost l> ibraries is concerned, is going to lead to confusion and puzzlement > from end-users and endless questions. What can it possibly cost to > actually explain of what "Boost dropping support for c++03" actually > consists, when it is finally decided what Boost is going to do in this > area ? If it is a matter of correct grammar or exposition in the > explanation, I will gladly volunteer to write it if no one else wants to > do so. +1. It sounds like what we're going to communicate to users is that Boost library authors or maintainers are no longer required to make their libraries support C++03. Which sounds fine to me. I don't think library maintainers should be confined by users (even if the users are other Boost libraries) if they don't want to be. Any Boost library maintainers that wish to continue supporting their C++03 users will do so. Any other Boost library maintainers that depend on such libraries can drop the dependency on those libraries. Glen

3 3

Re: [boost] A possible date for dropping c++03 support
by Glen Fernandes 29 Aug '18

29 Aug '18

James King wrote: > I thought Peter Dimov got it right from the comment I saw earlier. > The project would no longer spend time and effort on qualifying or testing > C++03 compatibility. CI builds and the test matrix would no longer > specifically test C++03. The default language level for b2 builds would be C++11. Sounds right. All of these above is a much more useful statement to make to users. > Individual repository maintainers could attempt to continue to qualify > for C++03 however once an upstream dependency begins to include > C++11 code, that effort would have to give way. If an upstream dependency only works in C++11 and above, and the library maintainer wants to support C++03, they can either: A) Drop the dependency and still support C++03 B) Drop C++03 support But again it will be up to that library maintainer. > As a developer both working on and > consuming boost I would appreciate the permission to start using C++11 > without fear. You will be able to start using C++11 in the libraries that you maintain, without fear. You won't be able to force another library maintainer to let you use C++11 unconditionally in their library if they want to support C++03 users. Glen

1 0

BOOST_FOREACH on a filesystem directory_iterator?
by Peter Dimov 29 Aug '18

29 Aug '18

Boost.Filesystem apparently contains support for BOOST_FOREACH: https://github.com/boostorg/filesystem/blob/5a93351bfdf859ee47245e042973922… But it doesn't work: #include <boost/filesystem.hpp> #include <boost/foreach.hpp> namespace fs = boost::filesystem; int main() { fs::directory_iterator it; BOOST_FOREACH( fs::path const& p, it ) { } } 1>c:\boost-git\develop\boost/range/end.hpp(48) : error C2039: 'end' : is not a member of 'boost::filesystem::directory_iterator' The fix is trivial, but I wonder... how did nobody notice? Is this feature never used?

2 1

Future of the MaybeBoost Hash Library
by Ilia K 29 Aug '18

29 Aug '18

Hi! I was looking for a header-only library to compute SHA512 and found a very interesting project: The MaybeBoost Hash Library ( https://www.cs.mcgill.ca/~smcmur/hash/) that implements SHA/MD5 ect. In 2010 there was a discussion ( http://boost.2283326.n4.nabble.com/rfc-Preliminary-Hash-Library-td2668722.h…) about making it one of the Boost subprojects but nothing happened. Maybe some of you guys know what's the matter? -- - Ilia

2 1

Re: [boost] A possible date for dropping c++03 support
by Glen Fernandes 28 Aug '18

28 Aug '18

Peter Dimov wrote: > Edward Diener wrote: > > Peter Dimov wrote: > > > If I post "Boost is dropping support for C++03" f.ex. on Twitter or > > > Reddit, every single user will immediately understand what that means. > > > :-) > > > > I am not a participant of either so some of your humor is lost on me, but > > I can guess that it suggests that you do not consider the intelligence of > > the average Twitter or Reddit participant to be very high. > > No, that's not at all what I meant. I meant what I said. Users will > immediately understand "Boost is dropping support for C++03". I doubt hat. After the "Boost is moving to CMake" announcement on Reddit, I have a different interpretation of what Reddit will understand from "Boost <anything>". We should do things first, then announce that we've done them. Glen

2 1

1.68 Getting Started links to 1.67
by Olaf van der Spek 28 Aug '18

28 Aug '18

Hi, > The most reliable way to get a copy of Boost is to download boost_1_67_0.7z or boost_1_67_0.zip and unpack it to install a complete Boost distribution.1 1.67? Actually the best way is to use vcpkg if possible (IMO). https://www.boost.org/doc/libs/1_68_0/more/getting_started/windows.html -- Olaf

6 18

Add an adapter to cover fast bit functions
by Evgeny Shulgin 28 Aug '18

28 Aug '18

Hi all, some days ago I opened a thread about DynamicBitset[1] (where I noted that a small piece of code may double the speed of a function), which received some interesting answers (you guys rock!) I looked deeper and realized that Boost doesn't have functionality to do common bit operations *really* fast. Let me explain - there are several places in Boost where we needed to solve typical tasks connected with bits in integers - like "get log2 of an integer rounded down" or "get the number of trailing zeros" or "count number of 1-bits", and Boost contributors have been inventing there a wheel everywhere, with varying degrees of optimality: [2] - [6]. Moreover, if a programmer writes a cross-platform app and has to do smth with this stuff, it's likely that for bit operations he will write a "naive" implementations - e.g. getting the log2(x) for O(log N), when it could be done for O(log log N), but with a more complicated code. Also, as well as "smart" algos, there are other methods to use - precalced tables, taking a small additional memory when needed [6], and intrinsics (that are CPU-specific). Combining of these methods (intrinsics when conveniently, or tables/algos) gives a notable shift in performance - here's my benchmark [7] from my tiny library [8]. Performance here varies from *9.2%* to *36.9%* of speed of related naive functions. I can tell you a usercase - as a hobby I'm writing a chess variants engine (where bitsets used to represent chess board, and its size is *not* fixed to 64), and bit operations' speed there is a matter of life and death. So, what do you think of an adapter header in Boost, covering all these operation of all integer types (and maybe some other one-liners like `is_bit_set(x, pos)` ), which keeps programmers out of platform specifics? It may look as smth like this [8] (I wrote only 3 functions, but it's enough to show the potential). I guess it can be placed somewhere to *Boost.Algorithm*, and supported with CI build tests of different platforms. P.S. The (incomplete) list of bit functions, that will give a *notable* better performance compared with naive algos and even some "smart" (because of precalc/intrinsics): - count of bits - parity of bit count - first 1-bit - last 1-bit (aka integer_log2(x)) - leading zeros - trailing zeros - swap(x) - returns x with the order of the bytes reversed; for example, 0xaabb becomes 0xbbaa. (bytes here are 8 bits exactly) - rotate_left(x, shift) - rotate_right(x, shift) Other functions may look like `is_set(x, pos) -> return x & (1 << pos)` and aren't so interesting. [1]: https://lists.boost.org/Archives/boost/2018/08/242825.php [2]: https://github.com/boostorg/integer/blob/develop/include/boost/integer/inte… [3]: https://github.com/boostorg/move/blob/develop/include/boost/move/algo/detai… [4]: https://github.com/boostorg/dynamic_bitset/blob/develop/include/boost/pendi… [5]: https://github.com/boostorg/integer/blob/develop/include/boost/integer/comm… (really almost the whole file) [6]: https://github.com/boostorg/dynamic_bitset/blob/develop/include/boost/detai… [7]: https://gist.githubusercontent.com/Izaron/8c94b76818393ffd93613d255033bb48/… [8]: https://github.com/Izaron/bit_algo/blob/master/include/bits.hpp

5 6

A possible date for dropping c++03 support
by Mike Dev 28 Aug '18

28 Aug '18

> -----Original Message----- > From: Glen Fernandes <glen.fernandes(a)gmail.com> > Sent: Tuesday, August 28, 2018 1:25 AM > To: mike.dev(a)gmx.de > Subject: Re: [boost] A possible date for dropping c++03 support > > On Mon, Aug 27, 2018 at 1:10 PM Mike Dev <mike.dev(a)gmx.de> wrote: > > Conditionally using a c++11/14/17 feature is (usually) not the problem > > although there are sometimes pitfalls as Peter mentioned. However, it also > > has limited utility. E.g. it doesn't make sense to simplify a function > > implementation using c++11 features like auto, range based for, decltype, > > constexpr instead of TMP, if you have to maintain the c++03 code path as well. > > In principle, you could conditionally get rid of some boost dependencies > > in c++11 mode, but again at the cost of maintaining two different code > > paths (as boost types often have slightly different semantics from c++11). > > So why do it? And you still can't deprecate the dependency itself because > > it is still needed in c++03 mode. > > Why do it? I do it when it provides some benefit to the users: > > e.g. If alternative implementation using C++14 constexpr results in > faster compilation for users. > If supporting C++11 move semantics results in better performance > for the users. > If supporting C++11 variadic templates results in a more > flexible interface for the users. > > i.e. If I'm the maintainer, and I'm happy to have that burden of > maintenance, why does anyone else care that I support > C++03/C++11/C++14 users, in addition to C++17 users? > > Yes, these are the high value proposition cases, that you mention. > > There's also no dependency to the user is there?. e.g. If a library > obtain std::addressof from <memory> in C++11 mode and doesn't source > it from Boost.Core, to the user, the library doesn't depend on > Boost.Core. > > > So except for cases with a very high value proposition (move semantics, > > simplified api, c++11 only functionality) or simple annotations (noexcept, > > override) using c++11 features *conditionally* is usually not all that > > beneficial. My hope here is that at some point, those boost libraries > > will finally start to use c++11 features *unconditionally* in order to > > simplify things - not add even more complexity in the form of conditional > > compilation. > > Simplify things for which party? Are you worried about users or Boost > library authors/maintainers? I don't see how users are inconvenienced > unless the user wants some feature only available in later C++ modes > that the library maintainer refuses to implement. > > Glen There are (at least) three problems: 1) Not all dependencies are private. If a library e.g. uses boost::function in its interface (in particular if it returns one) the user is also directly affected by changes to that dependency. 2) As you know, the c++ compilation model is incredibly leaky, meaning transitive dependencies are not hidden from the user. E.g. if you are using boost core in your header and I include it, I do get all the symbols (including macros) in my TU too. Boost has (usually) very good hygiene, so the main problems here are usually compilation times, sometimes code size and tools (code highlighting, static analysis, refactoring etc.) that either get slower or totally break e.g. because they don't have a perfect emulation of the compilation environment and don't know which code paths are the currently active ones or are just not able to understand all the TMP. 3) Not every library in boost is as well maintained as yours and I as a user prefer "cleaner / simpler" libraries because they a) tend to have fewer bugs, b) I can more easily modify things myself if necessary, c) the easier the life of the maintainer, the more likely he has time to add new functionalities. Finally, if boost can deprecate and at some point even remove some libraries, then their maintainers (in particular the CMT) can focus their time on different projects. Btw.: In case this was not clear: I'm not a boost contributor myself and for some time now, we (as in our company) are actively trying to avoid boost dependencies for various reasons that have more to do with boost-internal stuff and the boost eco system than with e.g. inconvenient interfaces. So yes, at least some end-users do really care about the internals of boost. But admittedly, I mostly work on (semi-) embedded projects where we have to compile (and on rare occasion even modify) boost ourselves - not sure how common that is. Best Mike

3 3

[gil] Template instantiation with GCC 8 is 50x slower than with clang++
by Mateusz Loskot 26 Aug '18

26 Aug '18

Hi, One of Boost.GIL users reported very long compilation times with GCC 7 and 8 https://github.com/boostorg/gil/issues/131 then, reproduced the problem with a minimal example without Boost GIL and MPL dependencies. The issue has been reported to GCC developers - I think users/developers of other Boost libraries may be interested too https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87107 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

[dynamic_bitset] Using of GCC built-in functions may increase performance of some methods
by Evgeny Shulgin 26 Aug '18

26 Aug '18

Hi all, when I was playing around the Boost.DynamicBitset library, I noticed the last lines of the count() function (which returns the number of bits in the bitset that are set): return do_count(m_bits.begin(), num_blocks(), Block(0), static_cast<value_to_type<(bool)mode> *>(0)); Well, this line was modified 10 years ago last time. Let's go deeper. GNU C provides several language features not found in ISO standard C. These include a bunch of bit operations - you can look at them here: https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html. For example, *__builtin_popcountll *counts the number of bits in an 'unsigned long long', so we can use this kind of code to calculate bits (don't judge, I wrote this fast and didn't think of coding standards): size_type res = 0; for (size_type i = 0; i < m_bits.size(); i++) { res += __builtin_popcountll(m_bits[i]); } I checked that m_bits[] and popcount() both work with 64-bit values on my machine. It halved the running time of a program that has a bitset and calls count() over and over again - here's the code <https://gist.github.com/Izaron/5005fed4184ee6483699191dc5ef3677> I used. These __builtin_XXX functions can be used everywhere where it's possible, with preprocessor directives. Or is it actually used and longer time means something else? I used the latest version of Boost.

6 8

[test][pull#151] Fix warning: BOOST_CLANG is not defined, evaluates to 0
by Mateusz Loskot 26 Aug '18

26 Aug '18

Hi, I've submitted a tiny fix for this annoyance: https://github.com/boostorg/test/pull/151 May I ask the library maintainers to merge it? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 1

GNOME outreachy
by Pranam Lashkari 26 Aug '18

26 Aug '18

GSoC just finished and it helped grow the community by adding few new students and maybe mentors to our Boost community. I was hoping why don't we also apply for GNOME outreachy also it is also similar to GSoC and can also help our community to grow. and by appearing in end of year internship in GNOME outreachy we can keep a flow of new contributors and motivate people to contribute to opensource throughout the year. Thank you, Pranam Lashkari

14 26

[regex] Drawing attention to link issue
by Antony Polukhin 24 Aug '18

24 Aug '18

Hello, The build flags for shared libraries are changing right now in b2. See https://github.com/boostorg/boost/pull/190 for more info. The thing is that Boost.Regex fails to link with those new flags, probably because of the https://github.com/boostorg/regex/issues/49 issue. If there's no simple solution for the above case, then please merge the https://github.com/boostorg/regex/pull/66/ . It should help. Thanks in advance!

2 2

[MSM] Still maintained?
by Christophe Henry 24 Aug '18

24 Aug '18

>Hi Boost-list, > >because I realized that my simple PR for Boost.MSM [1] (which makes it >compilable with C++17) and an even older one did not receive any >attention, I wonder if Boost.MSM is still actively maintained. > >The latest changes seem to be from around December 2017. > >Does anyone know, if Christophe is still active? > > >Best regards, >Deniz Hi Deniz, Sorry, I didn't have time to do it before vacations, I only merged your change to develop now. Thanks, Christophe

2 1

[type_traits][core] modularisation and moving stuff about (again)
by John Maddock 23 Aug '18

23 Aug '18

So... I have a couple of PR's to move some of type_traits into config so it can be used by core. It's a modest proposal so I can go with that I guess... but this moving stuff about all over the place just to satisfy dependencies does wind me up a bit - I know that I sometime struggle to figure out where stuff is on Github - half of Integer is in Config for example. How on earth would an end user figure that out in order to file a PR or a bug report? I know... "calm down dear" and all that ;) So radical suggestion - does type_traits just belong in core and lets be done with it? What would happen to the file history if we moved it (can I still "git blame")? DARFC, John. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

5 16

Re: [boost] [type_traits][core] modularisation and moving stuff about (again)
by Glen Fernandes 23 Aug '18

23 Aug '18

Andrey Semashev wrote: > I would rather encourage people use type traits, the official > interface. Boost.Config or Boost.TypeTraits could provide macros that > allow users to detect whether is_final is emulated or is the real > deal. One thing about this suggestion: If Boost.Config was to provide macros that tell users whether Boost.TypeTraits' boost::is_final<T>::value is emulated or the real deal, then the compiler detection logic currently in Boost.TypeTraits for detecting __is_final would already have to be duplicated in Boost.Config. That does not sound like a great idea. Right now TypeTraits provides both, which is better. i.e. It provides boost::is_final<T>::value and BOOST_IS_FINAL(T). The former uses the latter if it is defined, or is always false if not defined. If BOOST_IS_FINAL(T) and all its compiler detection logic lives in TypeTraits, then that all that compiler detection logic should not be duplicated in Config to provide a BOOST_HAS_IS_FINAL_INTRINSIC or similar feature detection macro. Glen

5 13

[test] I want my core dumped
by Alain Miniussi 22 Aug '18

22 Aug '18

Hi, I have assert in my library code, but when the assert fire in a test, the main function in minimal.hpp intercept the signal and explains that, yes, you asked for an abort, but no: [...] ../../../boost/test/minimal.hpp(136): exception "signal: SIGABRT (application abort requested)" caught in function: 'int main(int, char **)' Is there a way to avoid that behavior ? I need that core file. Thanks Alain

3 2

[multiprecision] Design question on variable precision types.
by John Maddock 22 Aug '18

22 Aug '18

Folks, I have a tricky design question that Boost.Multiprecision has been dodging relating to variable precision types - these have just expanded somewhat now that we support complex numbers via mpc as well as mpfr's reals etc. The basic use case is this: We have a set of numbers at very high precision, some calculations are performed on those directly, others we want to temporarily drop precision, get an approximate answer and perhaps later refine it. Generally speaking, performance trumps everything, on a really long running calculation 10-20% speedup can actually make a big difference (in $$'s in some cases if the CPU time is from the cloud). Up till now Boost.Multiprecision has been dodging this issue - it's actually pretty hard to program in a sane and consistent way, so the message has been "don't mix precisions" when using a type like boost::multiprecision::mpfr_float - just set what default you want and get on with it. But we really should do better than that. So... with the help of Danielle Brake I've been trying to nail this down in develop, what we have at present is: * Copy construction or move assignment copies the precision of the source. * Regular assignment retains the precision of the target variable. This is efficient in that assignment doesn't reallocate to a new precision, and provides an easy way to up/down sample precision when required. But it breaks equality after assignment. It does match what MPC/MPFR do in mpfr_set etc though. The fact that move assignment behaves differently from regular assignment bother me too - it's too easy to write code that triggers move semantics without noticing. The trouble is, being able to assign while retaining precision of source is sometimes useful too, so having move-assign behave differently provides a useful back door, but maybe one that's just too cute for it's own good? And then.... we get on to arithmetic. * Currently temporaries are created at current default precision. So it's easy to shoot yourself in the foot by not noticing that temporaries are being created in an expression and not having the default precision set correctly. I actually think this one might be solvable, but it's a huge job involving banning default constructors in all the backends to our number types, and then catching all the cases where they might have been used. * What should happen in "a = expression", where the variable used in "expression" are at different precision to a? The uncontroversial answer might be to adjust the result to the precision of a. But hold on... we have expression templates, and these can use variable a as working space while evaluating the expression... so the change in precision might occur *during* the computation and not after it. * Should we try to ban mixed precision arithmetic altogether? It's a tempting idea, but I can't see how to enforce it in code without also banning mixed precision assignment. Thanks for your consideration, John. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

2 1

[MSM] Still maintained?
by Deniz Bahadir 22 Aug '18

22 Aug '18

Hi Boost-list, because I realized that my simple PR for Boost.MSM [1] (which makes it compilable with C++17) and an even older one did not receive any attention, I wonder if Boost.MSM is still actively maintained. The latest changes seem to be from around December 2017. Does anyone know, if Christophe is still active? Best regards, Deniz [1] https://github.com/boostorg/msm/pull/15 -- BENOCS GmbH Dipl.-Inform. Deniz Bahadir Reuchlinstr. 10 D 10553 Berlin Germany Phone: +49 - 30 / 577 0004-22 Email: deniz.bahadir(a)benocs.com www.benocs.com Advisory Board (Chairman): Oliver Fietz Board of Management: Stephan Schröder, Dr.-Ing. Oliver Holschke, Dr.-Ing. Ingmar Poese Commercial Register: Amtsgericht Bonn HRB 19378

1 0

Increasing BOOST_PP_VARIADICS_SIZE
by Damien Buhl 20 Aug '18

20 Aug '18

Dear Edward, In comparison to BOOST_PP_SEQ, BOOST_PP_VARIADICS is limited to 64 elements while BOOST_PP_SEQ is limited 255. Is there a reason for the choice of 64 or could I patch BOOST_PP_VARIADICS to go as BOOST_PP_SEQ to a limit of 255 ? Or asked differently do you think there are in newer compilers/standards a way to have an unbounded BOOST_PP_VARIADICS implementation nowadays ? Warm Regards, -- Damien Buhl Software Developer +33 6 77 43 10 05

2 2

ABI issues with -std
by Peter Dimov 20 Aug '18

20 Aug '18

At some point, we'll need to acknowledge the problem which results from building Boost with one -std and user code with another, and deal with it somehow, if just by documenting. Most of our libraries don't suffer from it at the moment but Boost.System does, because of my changes; its ABI changes between 03/11/14. So I'm going to take the initial hit. :-) POSIX platforms have long been able to ignore ABI issues so we don't mangle the library names there at all, but now whether one builds Boost for C++03, C++11 or C++14 matters, and there's nothing to prevent linking C++xx to C++yy. Even with --layout=versioned, the cxxstd level is not encoded. The fact that the default C++ standard differs between g++ and clang++ doesn't help; when following the instructions of doing "b2 install", with g++6 and above you get C++14, but with g++5 or clang++ you get C++03. The latter is very rarely what one wants today.

7 26

Formal review request: Synapse
by Emil Dotchevski 16 Aug '18

16 Aug '18

Hello, I'm requesting a formal review for Synapse, a non-intrusive signal programming library. Synapse is a non-intrusive C++ signal programming library. It is able to register connections and emit signals from any C or C++ object of any type whatsoever. If two contexts share access to a C or C++ object, they can use that object as a randezvouz point of sorts, and communicate with each other through Synapse signals. A system of meta signals provides interoperability with other signal programming libraries and callback APIs. In particular Synapse can be used to safely register C++ function objects, including lambda functions, with any C-style callback API that is designed to work only with C function pointers. In a multi-thread environment signals can be emitted asynchronously and scheduled for synchronous execution when requested in other threads. There have been numerous improvements since the first review, including the the ability to create persistent connections which don't require the user to explicitly keep them alive. See https://zajo.github.io/boost-synapse/. Thanks, Emil

2 1

Strange libstdc++ versions in travis-ci testers
by Andrzej Krzemienski 15 Aug '18

15 Aug '18

Hi Everyone, Maybe someone could help me understand the configuration on the travis-ci testers. Whenever I push a new commit I get a number of failures from travis-ci about missing std::is_trivially_default_constructible from the standard library; like here: https://travis-ci.org/boostorg/optional/builds/397519342?utm_source=email&u… Some tests with Boost.Predef indicate that they are clang compiler 3.X, and clang 5 with libstdc++ of strange version nubers: macro BOOST_LIB_STD_GNU gives values 450400026 and 460700026, which would correspond to releases 2015-04-26 and 2016-07-26, but when I look at the release notes for GCC there are no releases mentioned of these dates: https://gcc.gnu.org/news.html Maybe someone knows what versions of libstdc++ these are? Or maybe I am missing something obvious? Regards, &rzej;

5 12

numeric directory/namespace
by Robert Ramey 14 Aug '18

14 Aug '18

I'm preparing to make adjustments to safe_numerics directory and namespace in preparation to incorporating safe_numerics into the official boost distributions. I have a couple of decisions to make that someone/everyone will want to weigh in on. There is already a directory boost_root/libs/numeric which seems to be an "umbrella" for libraries dealing with numerics. It includes conversion, interval, odeint and ublas. There is an index.html in there also. But instead of referring to the above libraries, it points to the ublas documentation. So it's sort of tempting the place safe numerics in libs as a sub directory. But I really have strong reservations about the whole concept of have this "umbrella" directory in the first place. Personally I'd just prefer to use boost_root/libs/safe_numerics. I don't think the extra structure adds anything and makes it harder to implement tools which scan the directories. It would also mean that I should ? use #include <boost/numeric/safe_numeric/ ....> and I'm not sure want to do that. Also I expect I'll want to sync the namespace boost::numeric::safe_numeric:: ... with the file system. It just seems more complex and flexible than it has to be. I see the future of boost as diminishing coupling between libraries and I see the current setup as not helping with this. Please don't wait to answer until I've made the changes. Robert Ramey

3 2

[container] [flat_map] Error with heterogeneous comparator and std::string_view
by Viktor Sehr 13 Aug '18

13 Aug '18

On MSVC (latest) the following code yields a compile error with flat_map, but not with std::map. I do not have the knowledge of std::less<> to resolve what causes the error. auto fm = boost::container::flat_map<std::string, int, std::less<> >{}; auto m = std::map<std::string, int, std::less<> >{}; auto k = std::string_view{ "my_key" }; auto x = m.find(k); // Compiles auto y = fm.find(k); // Does NOT compile Error message: 1>boost\container\flat_map.hpp(1314): error C2664: 'boost::container::vec_iterator<boost::container::dtl::pair<Key,T> *,true> boost::container::dtl::flat_tree<boost::container::dtl::pair<Key,T>,boost::container::dtl::select1st<Key>,Compare,boost::container::new_allocator<T2>>::find(const std::basic_string<char,std::char_traits<char>,std::allocator<char>> &) const': cannot convert argument 1 from 'const std::string_view' to 'const std::basic_string<char,std::char_traits<char>,std::allocator<char>> &' 1> with 1> [ 1> Key=std::string, 1> T=int, 1> Compare=std::less<void>, 1> T2=boost::container::dtl::pair<std::string,int> 1> ] 1> boost\container\flat_map.hpp(1314): note: Reason: cannot convert from 'const std::string_view' to 'const std::basic_string<char,std::char_traits<char>,std::allocator<char>>' 1> boost\container\flat_map.hpp(1314): note: No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called Best regards /Viktor

4 7

Library Federation
by Robert Ramey 12 Aug '18

12 Aug '18

I'm now taking steps to get safe numerics integrated into the boost distribution. It's reminded me of a running complaint I have about using boost. a) When I use anything boost, I'm required to do two things: i) run b2 headers to create a forwarding header in the boost directory ii) include via command line or INCLUDE variable to boost root. b) If I want to use safe_numerics before it is included in the boost distribution, I have to place safe_numerics into it's expected destination in the boost hierarchy and run b2 headers AGAIN to make things match up. This is even more problematic in that b2 headers is not invoked "automagically" in such a way that people don't know it's there. To me, this just makes it harder to use / test any new library with boost without dragging in access to a bunch of stuff I may not want. It inhibits those without beam foo from running the tests etc. This is why I did things the way I did. Now I'm getting ready to add it to the boost distribution, I'll change this to do it the "boost way". Not so much because I think it's better but in this case, consistency is better than variety. But I'm still unsatisfied with the situation. It's part of the reason that boost is avoided when possible by many people. Isn't there a better way? I think there might be. Rather than sprinkling a bunch of forwarding headers around my file system - which are "sticky" and need to be updated from time to time, how about depending on the "INCLUDE" environmental variables available in gcc and msvc and clang. Using "some method", I would be able generate this variable via some sort of batch script - not too tough. And work as I do now. But a) the script would be re-run when ever I changed projects so that it "stuck" in my file system. b) It could be smarter - include only the boost include directories I'm actually using - thus avoiding accidently including surprising stuff. c) We have tools which figure out boost dependencies automatically so I don't think it would be a big stretch to do this automagically. d) If my project is "larger" and includes a bunch of stuff from other libraries, I could add these in as well. This would give my the concept of "library federation" where my app is linked to some list defined as part of the project. I'm sure this concept also sort of exists. e) my pet request would be that I could say: tool application.cpp ... >include environment output to generate the env output for all the target apps. Of course one could you * wild cards as well. This would let me create one set on includes for building/running my test suite and a different one for examples and a different one for my "real" application. I'll stop there so as to leave opportunity for discussion. Robert Ramey

3 7

Please merge into boostorg superproject
by James E. King III 11 Aug '18

11 Aug '18

Please merge into boost superproject - these have passed CI and have been reviewed: https://github.com/boostorg/boost/pull/186 https://github.com/boostorg/boost/pull/181 Please decide what to do with: https://github.com/boostorg/boost/pull/39 (I can't tell if this is defunct?) https://github.com/boostorg/boost/pull/184 (do we want this in the superproject, or a submodule called boostorg/docker, or not at all?) Thanks, Jim

1 0

iostreams in 1.68.0
by James E. King III 11 Aug '18

11 Aug '18

Hi folks, just a note that none of the changes since 1.67.0 got into 1.68.0 master. They were on develop and never merged. I just merged them for 1.69.0. - Jim

1 0

[release] 1.69.0 open for merging
by Marshall Clow 10 Aug '18

10 Aug '18

The master branch is open for merging all stable changes from develop, including bug fixes and major upgrades to existing libraries. Breaking changes should be coordinated via the mailing list with the developers of the other libraries affected. New libraries may be added, but require permission of a release manager. In other words, merging does not require permission from a release manager, except for new libraries. Boost Calendar with the release schedule: http://www.boost.org/development/index.html Release schedule explanation: https://github.com/boostorg/boost/wiki/Release-Schedule Release practices for developers: http://svn.boost.org/trac/boost/wiki/ImprovingPractices -- The Boost Release Team

2 1

[release] Boost 1.68.0
by Marshall Clow 09 Aug '18

09 Aug '18

Release 1.68.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains 1 new libraryand numerous enhancements and bug fixes for existing libraries. For details, including download links, see <https://www.boost.org/users/news/version_1.68.0> You can also download directly from: <https://dl.bintray.com/boostorg/release/1.68.0/> To install this release on your system, see <https://www.boost.org/doc/libs/release/more/getting_started/index.html> Thanks to everyone who participated in this release. Thanks, -- The Boost Release Team

5 5

Re: [boost] [Boost-users] [release] Boost 1.68.0 Beta 1 -> warnings in gil, locale, geometry, asio, ublas, interprocess, atomic
by Frédéric 09 Aug '18

09 Aug '18

Here are some more warnings while using the libraries: * gil: boost/gil/extension/toolbox/image_types/indexed_image.hpp:190:5: warning: les qualificatifs de type sont ignorés sur le type retourné par la fonction [-Wignored-qualifiers] const std::size_t num_colors() const { return _num_colors; } ^~~~~ boost/gil/extension/dynamic_image/any_image_view.hpp:41:63: warning: unused parameter 'v' [-Wunused-parameter] template <typename T> result_type operator()(const T& v) const { return num_channels<T>::value; } boost/gil/extension/dynamic_image/algorithm.hpp:147:70: warning: unused parameter 'src' [-Wunused-parameter] template <typename V, typename Value> static void apply(const V& src, const Value& val) { throw std::bad_cast();} ^ boost/gil/extension/dynamic_image/algorithm.hpp:147:88: warning: unused parameter 'val' [-Wunused-parameter] template <typename V, typename Value> static void apply(const V& src, const Value& val) { throw std::bad_cast();} ^ boost/gil/extension/dynamic_image/image_view_factory.hpp:178:140: warning: unused parameter 'cc' [-Wunused-parameter] typename color_converted_view_type<any_image_view<ViewTypes>, DstP, CC>::type color_converted_view(const any_image_view<ViewTypes>& src,CC cc) {~ ^ boost/gil/extension/dynamic_image/image_view_factory.hpp:201:144: warning: unused parameter 'cc' [-Wunused-parameter] typename color_converted_view_type<any_image_view<ViewTypes>, DstP, CC>::type any_color_converted_view(const any_image_view<ViewTypes>& src,CC cc) {~ ^ boost/gil/io/device.hpp:446:31: warning: unused parameter 'data' [-Wunused-parameter] void write( const byte_t* data ^ boost/gil/io/device.hpp:447:31: warning: unused parameter 'count' [-Wunused-parameter] , std::size_t count ) ^ boost/gil/io/device.hpp:471:35: warning: unused parameter 'data' [-Wunused-parameter] std::size_t read( byte_t* data ^ boost/gil/io/device.hpp:472:35: warning: unused parameter 'count' [-Wunused-parameter] , std::size_t count ) ^ * locale: boost/locale/utf.hpp:224:17: warning: cette instruction peut poursuivre son chemin [-Wimplicit-fallthrough=] c = (c << 6) | ( tmp & 0x3F); ^ boost/locale/utf.hpp:225:13: note: ici case 2: ^~~~ boost/locale/utf.hpp:231:17: warning: cette instruction peut poursuivre son chemin [-Wimplicit-fallthrough=] c = (c << 6) | ( tmp & 0x3F); ^ boost/locale/utf.hpp:232:13: note: ici case 1: ^~~~ * geometry: boost/geometry/formulas/vertex_longitude.hpp:340:32: warning: unused parameter 'lon1' [-Wunused-parameter] static inline CT apply(CT& lon1, ^ boost/geometry/formulas/vertex_longitude.hpp:341:32: warning: unused parameter 'lat1' [-Wunused-parameter] CT& lat1, ^ boost/geometry/formulas/vertex_longitude.hpp:343:32: warning: unused parameter 'lat2' [-Wunused-parameter] CT& lat2, ^ boost/geometry/formulas/vertex_longitude.hpp:344:38: warning: unused parameter 'vertex_lat' [-Wunused-parameter] CT const& vertex_lat, ^ boost/geometry/formulas/vertex_longitude.hpp:345:32: warning: unused parameter 'alp1' [-Wunused-parameter] CT& alp1, ^ boost/geometry/formulas/vertex_longitude.hpp:346:44: warning: unused parameter 'azimuth_strategy' [-Wunused-parameter] Strategy const& azimuth_strategy) ^ boost/geometry/strategies/spherical/intersection.hpp:544:81: warning: unused parameter 'b2' [-Wunused-parameter] Point2 const& b1, Point2 const& b2, // in ^ boost/geometry/algorithms/detail/envelope/segment.hpp:156:61: warning: unused parameter 'lon1' [-Wunused-parameter] static inline void compute_box_corners(CalculationType& lon1, ^ boost/geometry/algorithms/detail/envelope/segment.hpp:158:61: warning: unused parameter 'lon2' [-Wunused-parameter] CalculationType& lon2, ^ boost/geometry/strategies/spherical/intersection.hpp:544:81: warning: unused parameter 'b2' [-Wunused-parameter] Point2 const& b1, Point2 const& b2, // in ^ * asio (windows 32 and 64 bits with mingw w64 + g++ 8.2.0) : /softs/win32-mingw-8.2.0/release/boost/include/boost/asio/detail/impl/win_iocp_socket_service_base.ipp: Dans la fonction membre « boost::system::error_code boost::asio::detail::win_iocp_socket_service_base::cancel(boost::asio::> /softs/win32-mingw-8.2.0/release/boost/include/boost/asio/detail/impl/win_iocp_socket_service_base.ipp:253:51: warning: transtypage entre types de fonctions incompatibles de « FARPROC » {aka « int (__attribute__((stdcall)) *)()> cancel_io_ex_t cancel_io_ex = (cancel_io_ex_t)cancel_io_ex_ptr; ^~~~~~~~~~~~~~~~ * ublas: /softs/lin64-gcc-8.2.0/debug/boost/include/boost/numeric/ublas/matrix_expression.hpp:2224:17: warning: cette instruction « if » ne protège pas… [-Wmisleading-indentation] if (it2_ != it2_end_) ^~ /softs/lin64-gcc-8.2.0/debug/boost/include/boost/numeric/ublas/matrix_expression.hpp:2227:21: note: …cette instruction, mais l'indentation de cette dernière est trompeuse car elle fait croire qu'elle est gardée par le « if » if (it2_ != it2_end_) { ^~ boost/numeric/ublas/functional.hpp:1673:57: warning: unused parameter 'size_i' [-Wunused-parameter] size_type upper_element (size_type i, size_type size_i, size_type j, size_type size_j) { ^ boost/numeric/ublas/functional.hpp:1673:88: warning: unused parameter 'size_j' [-Wunused-parameter] size_type upper_element (size_type i, size_type size_i, size_type j, size_type size_j) { ^ * interprocess (windows mingw-w64 + g++ 8.2.0 32/64 bits): In file included from boost/interprocess/errors.hpp:41, from boost/interprocess/exceptions.hpp:24, from boost/interprocess/sync/file_lock.hpp:24, from Progs/delypse-transfer.cpp:32: boost/interprocess/detail/win32_api.hpp:189:8: warning: « struct boost::interprocess::winapi::IUnknown_BIPC » a des fonctions virtuelles et un destructeur non virtuel accessible [-Wnon-virtual-dtor] struct IUnknown_BIPC ^~~~~~~~~~~~~ boost/interprocess/detail/win32_api.hpp:200:8: warning: la classe de base « struct boost::interprocess::winapi::IUnknown_BIPC » a un destructeur non virtuel accessible [-Wnon-virtual-dtor] struct IWbemClassObject_BIPC : public IUnknown_BIPC ^~~~~~~~~~~~~~~~~~~~~ boost/interprocess/detail/win32_api.hpp:200:8: warning: « struct boost::interprocess::winapi::IWbemClassObject_BIPC » a des fonctions virtuelles et un destructeur non virtuel accessible [-Wnon-virtual-dtor] boost/interprocess/detail/win32_api.hpp:306:8: warning: la classe de base « struct boost::interprocess::winapi::IUnknown_BIPC » a un destructeur non virtuel accessible [-Wnon-virtual-dtor] struct IWbemContext_BIPC : public IUnknown_BIPC ^~~~~~~~~~~~~~~~~ boost/interprocess/detail/win32_api.hpp:306:8: warning: « struct boost::interprocess::winapi::IWbemContext_BIPC » a des fonctions virtuelles et un destructeur non virtuel accessible [-Wnon-virtual-dtor] boost/interprocess/detail/win32_api.hpp:345:8: warning: la classe de base « struct boost::interprocess::winapi::IUnknown_BIPC » a un destructeur non virtuel accessible [-Wnon-virtual-dtor] struct IEnumWbemClassObject_BIPC : public IUnknown_BIPC ^~~~~~~~~~~~~~~~~~~~~~~~~ boost/interprocess/detail/win32_api.hpp:345:8: warning: « struct boost::interprocess::winapi::IEnumWbemClassObject_BIPC » a des fonctions virtuelles et un destructeur non virtuel accessible [-Wnon-virtual-dtor] boost/interprocess/detail/win32_api.hpp:369:8: warning: la classe de base « struct boost::interprocess::winapi::IUnknown_BIPC » a un destructeur non virtuel accessible [-Wnon-virtual-dtor] struct IWbemServices_BIPC : public IUnknown_BIPC ^~~~~~~~~~~~~~~~~~ boost/interprocess/detail/win32_api.hpp:369:8: warning: « struct boost::interprocess::winapi::IWbemServices_BIPC » a des fonctions virtuelles et un destructeur non virtuel accessible [-Wnon-virtual-dtor] boost/interprocess/detail/win32_api.hpp:518:8: warning: la classe de base « struct boost::interprocess::winapi::IUnknown_BIPC » a un destructeur non virtuel accessible [-Wnon-virtual-dtor] struct IWbemLocator_BIPC : public IUnknown_BIPC ^~~~~~~~~~~~~~~~~ boost/interprocess/detail/win32_api.hpp:518:8: warning: « struct boost::interprocess::winapi::IWbemLocator_BIPC » a des fonctions virtuelles et un destructeur non virtuel accessible [-Wnon-virtual-dtor] In file included from boost/interprocess/errors.hpp:41, from boost/interprocess/exceptions.hpp:24, from boost/interprocess/sync/file_lock.hpp:24, from Progs/delypse-transfer.cpp:32: boost/interprocess/detail/win32_api.hpp: Dans la fonction « bool boost::interprocess::winapi::get_system_time_of_day_information(boost::interprocess::winapi::system_timeofday_information&) »: boost/interprocess/detail/win32_api.hpp:1676:58: warning: transtypage entre types de fonctions incompatibles de « boost::interprocess::winapi::farproc_t » {aka « int (__attribute__((stdcall)) *)() »} vers « boost::interprocess:> dll_func::get(dll_func::NtQuerySystemInformation); ^ boost/interprocess/detail/win32_api.hpp: Dans la fonction « bool boost::interprocess::winapi::unlink_file(const char*) »: boost/interprocess/detail/win32_api.hpp:1892:78: warning: transtypage entre types de fonctions incompatibles de « boost::interprocess::winapi::farproc_t » {aka « int (__attribute__((stdcall)) *)() »} vers « boost::interprocess:> (NtSetInformationFile_t)dll_func::get(dll_func::NtSetInformationFile); ^ boost/interprocess/detail/win32_api.hpp:1894:94: warning: transtypage entre types de fonctions incompatibles de « boost::interprocess::winapi::farproc_t » {aka « int (__attribute__((stdcall)) *)() »} vers « boost::interprocess:> NtQueryObject_t pNtQueryObject = (NtQueryObject_t)dll_func::get(dll_func::NtQueryObject); ^ boost/interprocess/detail/win32_api.hpp:1966:85: warning: transtypage entre types de fonctions incompatibles de « boost::interprocess::winapi::farproc_t » {aka « int (__attribute__((stdcall)) *)() »} vers « boost::interprocess:> NtOpenFile_t pNtOpenFile = (NtOpenFile_t)dll_func::get(dll_func::NtOpenFile); ^ boost/interprocess/detail/win32_api.hpp:1967:73: warning: transtypage entre types de fonctions incompatibles de « boost::interprocess::winapi::farproc_t » {aka « int (__attribute__((stdcall)) *)() »} vers « boost::interprocess:> NtClose_t pNtClose = (NtClose_t)dll_func::get(dll_func::NtClose); ^ boost/interprocess/detail/win32_api.hpp: Dans la fonction « bool boost::interprocess::winapi::get_file_mapping_size(void*, long long int&) »: boost/interprocess/detail/win32_api.hpp:2413:63: warning: transtypage entre types de fonctions incompatibles de « boost::interprocess::winapi::farproc_t » {aka « int (__attribute__((stdcall)) *)() »} vers « boost::interprocess:> (NtQuerySection_t)dll_func::get(dll_func::NtQuerySection); ^ boost/interprocess/detail/win32_api.hpp: Dans la fonction « bool boost::interprocess::winapi::get_semaphore_info(void*, long int&, long int&) »: boost/interprocess/detail/win32_api.hpp:2426:86: warning: transtypage entre types de fonctions incompatibles de « boost::interprocess::winapi::farproc_t » {aka « int (__attribute__((stdcall)) *)() »} vers « boost::interprocess:> (winapi::NtQuerySemaphore_t)dll_func::get(winapi::dll_func::NtQuerySemaphore); ^ boost/interprocess/detail/win32_api.hpp: Dans la fonction « bool boost::interprocess::winapi::query_timer_resolution(long unsigned int*, long unsigned int*, long unsigned int*) »: boost/interprocess/detail/win32_api.hpp:2437:98: warning: transtypage entre types de fonctions incompatibles de « boost::interprocess::winapi::farproc_t » {aka « int (__attribute__((stdcall)) *)() »} vers « boost::interprocess:> (winapi::NtQueryTimerResolution_t)dll_func::get(winapi::dll_func::NtQueryTimerResolution); ^ boost/interprocess/detail/win32_api.hpp: Dans la fonction « bool boost::interprocess::winapi::query_performance_counter(long long int*) »: boost/interprocess/detail/win32_api.hpp:2444:57: warning: transtypage entre types de fonctions incompatibles de « boost::interprocess::winapi::farproc_t » {aka « int (__attribute__((stdcall)) *)() »} vers « boost::interprocess:> dll_func::get(dll_func::QueryPerformanceCounter); ^ boost/interprocess/detail/win32_api.hpp: Dans la fonction « bool boost::interprocess::winapi::query_performance_frequency(long long int*) »: boost/interprocess/detail/win32_api.hpp:2451:59: warning: transtypage entre types de fonctions incompatibles de « boost::interprocess::winapi::farproc_t » {aka « int (__attribute__((stdcall)) *)() »} vers « boost::interprocess:> dll_func::get(dll_func::QueryPerformanceFrequency); ^ * atomic (OSX): boost/include/boost/atomic/detail/ops_gcc_x86_dcas.hpp:269:113: warning: unused parameter 'order' [-Wunused-parameter] static BOOST_FORCEINLINE storage_type exchange(storage_type volatile& storage, storage_type v, memory_order order) BOOST_NOEXCEPT

4 6

Note: the Master branch is not yet open for merging
by Marshall Clow 09 Aug '18

09 Aug '18

Even though we have a release, I've got some tagging to do, etc. The master branch will be open tomorrow. -- Marshall

1 0

[release] Boost 1.68.0 Release Candidate 1
by Marshall Clow 05 Aug '18

05 Aug '18

The release candidates for the 1.68.0 release are now available at: <https://dl.bintray.com/boostorg/release/1.68.0/source/> The SHA256 checksums are as follows: 59804d8fad02cf3b09485f3dbc0f9097c05fc1e0123f0c133b35a6c6f601109a boost_1_68_0_rc1.7z 7f6130bc3cf65f56a618888ce9d5ea704fa10b462be126ad053e80e553d6d8b7 boost_1_68_0_rc1.tar.bz2 da3411ea45622579d419bfda66f45cd0f8c32a181d84adfa936f5688388995cf boost_1_68_0_rc1.tar.gz 3b1db0b67079266c40b98329d85916e910bbadfc3db3e860c049056788d4d5cd boost_1_68_0_rc1.zip As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. The web site will be updated today as well.

6 8

[release] Boost 1.68.0 Beta 1
by Marshall Clow 02 Aug '18

02 Aug '18

Boost release 1.67.0 beta 1 is now available at: https://dl.bintray.com/boostorg/beta/1.68.0.beta1/source/ The files are identical to the RC2 that was posted on Friday. The SHA256 checksums are as follows: 961d2bdc74c1499c931b32098842abba8883b1a89ef5c8f8f0ab0aff771a3ce5 boost_1_68_0_b1_rc2.7z 0364846258648e39908ca7cebfc2d2216eef6980c32aaf8276d2cfe73ef012e3 boost_1_68_0_b1_rc2.tar.bz2 d99105685a68907a76b0479ecde77915423246236ef0db9cb846c5bfc09b41f3 boost_1_68_0_b1_rc2.tar.gz 6158e0e961bfb0d8adeb2ea70337b08504668258025f0a873fb21eee3436d22e boost_1_68_0_b1_rc2.zip For details of what's in the release, see <http://www.boost.org/users/history/version_1_68_0.html>. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

3 7

Moving wiki/Guidelines/WarningsGuidelines
by Mateusz Loskot 02 Aug '18

02 Aug '18

Hi, Paul Bristow suggested [1] "We might also re-host this document somewhere on github/boostorg?" [1] https://lists.boost.org/Archives/boost/2018/07/242617.php I'd like to edit and move the wiki page away from Trac. IMHO, it is reasonable to host it not on GitHub wiki but on boost.org along other guidelines, for example, at https://www.boost.org/development/warnings.html - It is easy to update website via pull requests. - Any updates would be a subject of some review at least Thoughts? Objections? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

3 7

[release] 1.68.0 closed for release
by Marshall Clow 02 Aug '18

02 Aug '18

The master branch is now closed for all changes except by permission. The commit-bot isn't running on master, so the super project will need to be manually updated for any changes. If all goes well, the release candidate should be out tomorrow. Thanks, -- The Boost Release Team

1 0

[release] 1.68.0 post-beta merges
by Marshall Clow 01 Aug '18

01 Aug '18

The master branch is is now open for post-beta merges, but only as described in the Post-Beta Merge Policy. See <https://github.com/boostorg/boost/wiki/Release-Beta-Merge-Policy> The master branch will close for the 1.68.0 release on August 1st. -- Marshall

11 34

[filesystem] PR backlog needs attention
by James E. King III 01 Aug '18

01 Aug '18

There are 29 open PRs going back 3 years. This backlog needs some attention. Some of the pull requests (like documentation changes to fix typos) are trivial. I ran into a warning while building another library that I found was already submitted as a fix in the PRs, but has missed the 1.68.0 release now. Thanks, Jim

4 5

Re: [boost] [Boost-users] [release] Boost 1.68.0 Beta 1 -> warnings in filesystem, locale, thread, stacktrace, container
by Frédéric 30 Jul '18

30 Jul '18

Hi, I have tested 1.68.0 on linux x86_64 with the following compilers: - g++ 8.2.0, - clang++ 5.0.2, - mingw-w64 + g++ 8.2.0 cross compiling to windows 32 bits, - mingw-w64 + g++ 8.2.0 cross compiling to windows 64 bits, - clang++ 5.0.2 cross compiliing to OSX 10.9 32 bits, - clang++ 5.0.2 cross compiliing to OSX 10.9 64 bits. I did not find any major issue. Just those warnings while building the libraries: * filesystem (g++ 8.2.0 and clang++ 5.0.2 on linux x86_64): libs/filesystem/src/operations.cpp: Dans la fonction « int {anonymous}::readdir_r_simulator(DIR*, dirent*, dirent**) »: libs/filesystem/src/operations.cpp:2126:18: warning: « int readdir_r(DIR*, dirent*, dirent**) » est obsolète [-Wdeprecated-declarations] { return ::readdir_r(dirp, entry, result); } ^~~~~~~~~ In file included from /usr/include/features.h:423, from /softs/gcc-8.2.0/include/c++/8.2.0/x86_64-pc-linux-gnu/bits/os_defines.h:39, from /softs/gcc-8.2.0/include/c++/8.2.0/x86_64-pc-linux-gnu/bits/c++config.h:508, from /softs/gcc-8.2.0/include/c++/8.2.0/cstddef:49, from ./boost/config/compiler/gcc.hpp:165, from ./boost/config.hpp:39, from ./boost/filesystem/operations.hpp:18, from libs/filesystem/src/operations.cpp:68: /usr/include/dirent.h:189:12: note: déclaré ici extern int __REDIRECT (readdir_r, ^~~~~~~~~~ * locale (many more than that one about deprecated std::auto_ptr): I wonder when auto_ptr will be removed but it would be nice to change it to unique_ptr. In file included from libs/locale/src/util/default_locale.cpp:10: ./boost/locale/util.hpp:180:28: warning: « template<class> class std::auto_ptr » est obsolète [-Wdeprecated-declarations] BOOST_LOCALE_DECL std::auto_ptr<base_converter> create_utf8_converter(); ^~~~~~~~ In file included from /softs/gcc-8.2.0/include/c++/8.2.0/bits/locale_conv.h:41, from /softs/gcc-8.2.0/include/c++/8.2.0/locale:43, from ./boost/locale/util.hpp:10, from libs/locale/src/util/default_locale.cpp:10: /softs/gcc-8.2.0/include/c++/8.2.0/bits/unique_ptr.h:53:28: note: déclaré ici template<typename> class auto_ptr; ^~~~~~~~ * thead with mingw w64 cross compiling to windows 32 bits on linux x86_64 with g++ 8.2.0: I guess this warning is due to the fact that time_t is 32 bits on windows 32 bits so this looks dangerous to me. libs/thread/src/win32/thread_primitives.cpp: Dans la fonction « boost::detail::win32::ticks_type boost::detail::win32::{anonymous}::get_tick_count_init() »: libs/thread/src/win32/thread_primitives.cpp:97:120: warning: transtypage entre types de fonctions incompatibles de « boost::winapi::FARPROC_ » {aka « int (__attribute__((stdcall)) *)() »} vers « boost::detail::win32::detail::gettickcount64_t » {aka « long long unsigned int (__attribute__((stdcall)) *)() »} [-Wcast-function-type] (boost::detail::win32::detail::gettickcount64_t)boost::winapi::get_proc_address(hKernel32, "GetTickCount64"); * stacktrace (windows 32 and 64 bits): In file included from ./boost/winapi/file_management.hpp:17, from ./boost/stacktrace/detail/safe_dump_win.ipp:20, from ./boost/stacktrace/safe_dump_to.hpp:210, from ./boost/stacktrace/frame.hpp:20, from ./boost/stacktrace/detail/frame_unwind.ipp:15, from libs/stacktrace/build/../src/basic.cpp:14: ./boost/winapi/overlapped.hpp:38:9: warning: le C++ ISO interdit les structures anonymes [-Wpedantic] }; ^ * iostreams (windows 64 bits): libs/iostreams/src/mapped_file.cpp: Dans la fonction membre « void boost::iostreams::detail::mapped_file_impl::try_map_file(boost::iostreams::detail::mapped_file_impl::param_type) »: libs/iostreams/src/mapped_file.cpp:324:29: warning: comparaison d'expressions entières de types signés différents: « boost::iostreams::stream_offset » {aka « long long int »} et « boost::iostreams::mapped_file_source::size_type » {aka « long long unsigned int »} [-Wsign-compare] (SIZE_T) (size_ != max_length ? size_ : 0), ~~~~~~^~~~~~~~~~~~~ gcc.compile.c++ bin.v2/libs/iostreams/build/gcc-8.2.0/debug/link-static/target-os-windows/threading-multi/gzip.o * container (OSX 32 and 64 bits, clang 5.0.2): many locations with this warning: In file included from libs/container/src/alloc_lib.c:24: In file included from libs/container/src/dlmalloc_ext_2_8_6.c:36: libs/container/src/dlmalloc_2_8_6.c:4085:27: warning: 'sbrk' is deprecated [-Wdeprecated-declarations] char* base = (char*)CALL_MORECORE(0); ^ libs/container/src/dlmalloc_2_8_6.c:1714:37: note: expanded from macro 'CALL_MORECORE' #define CALL_MORECORE(S) MORECORE_DEFAULT(S) ^ libs/container/src/dlmalloc_2_8_6.c:666:26: note: expanded from macro 'MORECORE_DEFAULT' #define MORECORE_DEFAULT sbrk ^ /softs/osxcross-10.9-5.0.2/bin/../SDK/MacOSX10.9.sdk/usr/include/unistd.h:580:1: note: 'sbrk' has been explicitly marked deprecated here __deprecated ^ /softs/osxcross-10.9-5.0.2/bin/../SDK/MacOSX10.9.sdk/usr/include/sys/cdefs.h:156:37: note: expanded from macro '__deprecated' #define __deprecated __attribute__((deprecated)) ^

2 2

Release notes piling up
by James E. King III 30 Jul '18

30 Jul '18

There are 12 PRs for updating the documentation (they are going to have merge conflicts)... who is managing that for this release cycle? https://github.com/boostorg/website/pulls - Jim

5 8