May 2019 - Boost - lists.boost.org

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

13 Aug '24

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

49 200

[asio][coroutine] forbid_suspend blocks
by Vinícius dos Santos Oliveira 07 Aug '19

07 Aug '19

I've implemented a dumb linter using Python + clang API that allows you to mark certain blocks as “atomic in respect to coroutines” using C++11 attributes. Usage example follows: void f() { int yield; g(yield); [[bt::forbid_suspend]] { // Comment this call to make linter accept the code g(yield); t(); } } You can change bt::forbid_suspend to another identifier by tuning settings on the beginning of the script. The prefix forbid was inspired by Rust's linters[1] as you cannot disallow the linter from inside the forbid_suspend block. Some limitations follow: - A suspend point is identified by looking references to any id equals to yield in the last argument passed to function calls. It means that yield[ignored_ec] and alike will be correctly identified, but it needs to be named yield and it needs to be the last argument to the function call. - I haven't found a way to extract attributes related to COMPOUND_STMT nodes with clang API, so I manually look for token gaps and do a simple regex. It means you cannot use macros to [[bt::forbid_suspend]] as the macro won't be expanded. - You better call the script with '-x c++' and also ' -I/usr/lib/clang/5.0.1/include'. Like I've said in the beginning of the email, it's a *dumb* linter, which means it doesn't try to handle all cases. Therefore, I don't hope to do many changes to it or maintain it to work against newer releases of clang and I'm only uploading it to gist (not fullblow Github): < https://gist.github.com/vinipsmaker2/d930fbe5b7597432b021effe618da171>. It should also be easy to hack as it is very small. I'm releasing the linter under public domain. Enjoy. I have been using fibers in a daily basis on the last months of my job to solve networking problems on a gateway project. Some of the technologies I use are: - Boost.Asio and its spawn function. - A few custom synchronization primitives for the fibers (e.g. mutex, semaphore). - Eventually I'll have to write a custom spawn function that returns a joinable handle so I can kill the usage of a fiber::barrier in a few places. I've been using the linter for about a week already and looks fine. My use case are: - To prevent iterator invalidation in regions accessing shared variables. - To guarantee events order in algorithms that handle races (cannot yield while task YYY hasn't finished). The project I use it in is not an open source project, so I cannot talk much more about it. Also, I don't claim my solution is original. I wouldn't be surprised if the very same solution exists in the wild (please let me know if you know of a similar approach). This is not a new problem. It is know for some time. For instance, in P0171, Gor Nishanov noted this same problem: “In coroutines the suspend point is clearly marked with await, which tells the reader that something unusual happens in this function and allows the reader, for example, to confirm whether the lifetimes of the objects of interest align with the lifetime of the coroutine or not, whether some locks need to be acquired to protect some concurrently accessed data, and whether some locks need to be released before the execution reaches the suspend point.” — <http://open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0171r0.html>, 2015 However, the solution he presented was to manually examine whole blocks of code without help from the compiler. I argue that the solution he presented is as error-prone as manually looking for exit paths that don't free acquired resources in languages lacking RAII. And I've been spoiled too much by RAII. Furthermore, I take this comment of his with highly suspicious look: “Since we are on the subject of maintenance nightmares, we would like to offer a conjecture that the absence of the await in P0114 is a likely source of many maintenance nightmares. Without a syntactic marker to signal to the person reading the code that something funny is going on, it is impossible to tell whether the following code is correct or not” — http://open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0171r0.html If I had to give a vote to the proposal he was defending or Chris' proposal, I'd probably have chosen Chris'. [1] https://doc.rust-lang.org/reference/attributes.html# lint-check-attributes -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/

2 3

Mother of all Variants
by Robert Ramey 05 Jul '19

05 Jul '19

I'm way out of my depth in the variant discussion. Seems to me it revolves around all the trade offs regarding design choices. Could we perhaps decide not to decide. Suppose we create a type which looks like: template< bool BasicGuaranteeSupported, bool StrongGuaranteeSupported, bool EmptyStateProhibited, bool AssignmentSupported, bool MoveSupported, class T ... > struct mother_of_variants{ // some trivial mp11 code }; Now we could define: using boost_variant = mother_of_all variants< bool true, //BasicGuaranteeSupported, bool true, //StrongGuaranteeSupported, bool true, //EmptyStateProhibited, bool true, //AssignmentSupported, bool true, //MoveSupported, >; std_variant, std_optional, std_expect, boost_outcome, etc. would be similarly defined. And some "extras" like no_except_variant, trivial_variant, etc. would be added. and of course my favorite candidate: using safe_variant = mother_of_all variants< bool true, //BasicGuaranteeSupported, bool true, //StrongGuaranteeSupported, bool true, //EmptyStateProhibited, bool false, //AssignmentSupported, bool false //MoveSupported, >; In addition, we'd have some type traits: mother_of_all_variants::no_runtime_allocation<mov>; mother_of_all_variants::no_double_instancen<mov>; mother_of_all_variants::is_mother_of_all_variants<mov>; etc. Just think that of all the time we've spent on discussions about optional, expected, std::variant, boost::variant, etc. At this rate, these discussions will keep hounding us forever. Of course I realize that the main purpose of having these variants of variants is to justify the discussions - but perhaps we might be ready for a new topic. Robert Ramey

17 57

[ boost.out_ptr ] [ Review Endorsement ] New Library targeting C++11
by JeanHeyd Meneide 04 Jun '19

04 Jun '19

Dear Boost Community, After a lot of work and discussion in-person, via e-mail, and on the Slack, I would like to ask for the library boost.out_ptr <https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr.adoc> -- targeting C++11 -- to be endorsed for review. Documentation: ascii doc-ready and readable on GitHub <https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr.adoc> Repository: GitHub <https://github.com/ThePhD/out_ptr> Standards Proposal: p1132 <https://thephd.github.io/vendor/future_cxx/papers/d1132.html> (accepted for and targeting C++20) boost.out_ptr is a library for making it easy to interoperate between smart pointers and traditional C-style initialization and allocation interfaces. It also enables doing so in a way that allows library authors to opt-into speed optimizations for their smart pointers that give them performance equivalent to typical C pointers (see benchmarks <https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr/benchmarks.adoc> and the Standard C++ proposal <https://thephd.github.io/vendor/future_cxx/papers/d1132.html#perf> for more details). Many thanks to the in-person discussion during Library in a Week at C++Now, which helped shape the implementation and yield the final Rationale <https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr/rationale.adoc>. Many thanks to Ezra (eracpp) for a lot of the quick, easy-to-read examples that became part of the documentation. Sincerely, JeanHeyd Meneide

11 19

Re: [boost] [Boost.Config] Detect compiler support for std::current_exception
by dariomt＠gmail.com 03 Jun '19

03 Jun '19

> > >>> Hi all, > >>> > >>> I'm working on a Boost.Exception issue [1] and I need to detect > compiler > >>> support of std::current_exception. In the issue there is a suggestion > to > >>> use #if __cplusplus > 199711L but that does not work for my use case > >>> (VS2015 reports __cplusplus = 199711L). > >> > >> MSVC defines _MSVC_LANG for this[1]. At least, it used to. However, it > >> would be cleaner to have a dedicated macro in Boost.Config for this. > >> > > Totally agree. > > > >> > >>> Is it possible to add a config macro for this? > >>> Or is there a good enough existing macro I can use? > >> > >> I don't think there is. Something like BOOST_NO_CXX11_HDR_EXCEPTION > >> would be useful. > > > > I would need to detect support for std::current_exception, not the > presence > > of header <exception>, so I would think that > > BOOST_NO_CXX11_CURRENT_EXCEPTION is what I need, right? > > BOOST_NO_CXX11_HDR_EXCEPTION, as all BOOST_NO_CXX11_HDR_* macros, detect > that the header not only exists, but is usable and contains all major > components described by the standard. In case of > BOOST_NO_CXX11_HDR_EXCEPTION, that would mean std::exception_ptr, > std::current_exception, std::rethrow_exception, std::make_exception_ptr, > etc. You need at least std::exception_ptr and std::current_exception. > Thanks, that makes sense! > > Should I open an issue in github for Boost.Config? > > Yes, or better yet - make a PR. > Added github Issue #284 [1], I'll try to come up with a PR. Wondering how deep the rabbit hole goes... ^_^ Regards [1] https://github.com/boostorg/config/issues/284

2 2

Downloads of boost from Bintray.com are temporarily unavailable
by Marshall Clow 30 May '19

30 May '19

Apparently, Boost is being downloaded over 6000 times/day from Bintray, and we've reached the limits of their bandwidth for the month. We're trying to get them to increase our quota (and see if there's someone who is downloading boost over and over again), but at the present time, downloads from bintray are being rejected. Hopefully this will be a temporary situation. -- Marshall (boost release manager)

3 2

disjoint_sets and graph appear to be Link previously defined to another file,
by Paul A. Bristow 30 May '19

30 May '19

I have just done a full GIT update from Boost develop. (and bootstrap to rebuild b2.exe) When I try to recreate the headers or run any b2 run, I now get Performing configuration checks - default address-model : 32-bit - default architecture : x86 - symlinks supported : yes error: Cannot create link ..\..\..\boost\pending\detail\disjoint_sets.hpp to ..\..\graph\include\boost\pending\detail\disjoint_sets.hpp. error: Link previously defined to another file, ..\..\disjoint_sets\include\boost\pending\detail\disjoint_sets.hpp. I deleted all the bin.v2/libs files but this has no effect. I have deleted /disjoint_sets to get going again (as I not using either graph or disjoint_sets). What am I doing wrong? Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

2 1

Follow the work on Google summer of code
by David Bellot 30 May '19

30 May '19

Hi Boost community, you can follow the work of our students on this github page https://github.com/BoostGSoC19 They are all working very hard already. Best regards, David

1 0

Re: [boost] Aggregate usage statistics request for Boost
by Dimitri John Ledkov 29 May '19

29 May '19

On Fri, 3 May 2019 at 10:03, Joshua Marshall <jrmarsha(a)mtu.edu> wrote: > > Hello all, > > A few of us with Boost are trying to decide support of different compilers. I know that Ubuntu collects some anonymized statistics which could help us some. Could someone please collect and forward the following bits of information to boost(a)lists.boost.org : > Install base size of Ubuntu 14.04 to 19.04 > Per OS version, what versions of GCC, Clang, and Boost are installed on what percentage of the install base. > -- > ubuntu-devel mailing list > ubuntu-devel(a)lists.ubuntu.com > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel >From Ubuntu development point of view, our biggest concern is that no stable releases of boost claim to be supported or tested with the next GCC compiler. For example, for 19.10 we will be switching to GCC-9 by default, yet boost 1.70.0 primary test compilers do not include GCC-9 for Linux. Ideally, we would like to see boost upstream include next-gcc as part of primary or additional test compilers for every boost release. W.R.T. Install base size ratios and which boosts are in use -> we do not have statistics on what you are asking for. I.e. default compilers are installed on all systems (to support dkms), some boost runtime libraries are also always installed as quite a few packages depend on boost runtimes. And dev packages are not tracked and impossible to tell if they are installed by accident or on purpose. We can say generically, that our LTS releases are used a lot more than non-LTS releases, and thus by extension default compilers and boost versions within those are used more. And LTS cycles do follow an overlap, where for a while after one LTS release, the previous LTS is the most popular, and then it rolls over eventually. Our default compiler is GCC for all packages. LLVM toolchain is used for mesa and intel graphics compiler, and like that's it. Mesa requirements are what drives LLVM toolchain updates in Ubuntu. Next LTS 20.04 -> to be determined Current Development 19.10 -> 1.67.0, gcc 8.3 being switched to gcc 9, clang 8.0 (or newer) Current LTS releases (most popular at the moment) 18.04 -> 1.65.1, gcc 7.4, clang 6.0 16.04 -> 1.58.0, gcc 5.3, clang 3.8 Past basic support, in Extended Maintainance Support LTS (very old, and declining in usage) 14.04 -> 1.54.0, gcc 4.8, clang 3.4 12.04 -> 1.48.0, gcc 4.6, clang 3.0 -- Regards, Dimitri.

3 3

Re: [boost] [Boost.Config] Detect compiler support for std::current_exception
by dariomt＠gmail.com 29 May '19

29 May '19

> > > > Hi all, > > > > I'm working on a Boost.Exception issue [1] and I need to detect compiler > > support of std::current_exception. In the issue there is a suggestion to > > use #if __cplusplus > 199711L but that does not work for my use case > > (VS2015 reports __cplusplus = 199711L). > > MSVC defines _MSVC_LANG for this[1]. At least, it used to. However, it > would be cleaner to have a dedicated macro in Boost.Config for this. > Totally agree. > > > Is it possible to add a config macro for this? > > Or is there a good enough existing macro I can use? > > I don't think there is. Something like BOOST_NO_CXX11_HDR_EXCEPTION > would be useful. > I would need to detect support for std::current_exception, not the presence of header <exception>, so I would think that BOOST_NO_CXX11_CURRENT_EXCEPTION is what I need, right? So that I can #ifndef BOOST_NO_CXX11_CURRENT_EXCEPTION // I can use std::current_exception() unconditionally here #endif Should I open an issue in github for Boost.Config?

3 2

[Boost.Config] Detect compiler support for std::current_exception
by dariomt＠gmail.com 27 May '19

27 May '19

Hi all, I'm working on a Boost.Exception issue [1] and I need to detect compiler support of std::current_exception. In the issue there is a suggestion to use #if __cplusplus > 199711L but that does not work for my use case (VS2015 reports __cplusplus = 199711L). Is it possible to add a config macro for this? Or is there a good enough existing macro I can use? Thanks in advance [1] https://github.com/boostorg/exception/issues/10

2 1

My messages do not reach boost-request@lists.boost.org
by dariomt＠gmail.com 27 May '19

27 May '19

Hi, I've tried a couple of times to write to the Boost Developers mail list, but I don't see my messages getting through to the list. I seem to reach the Boost Users mil list without problems. Could you please review why this is happening? Thanks in advance!

1 0

Re: [boost] bcp namespace aliasing broken, impacts package providers, shared libraries unusable since 1.69
by Peter Dimov 26 May '19

26 May '19

> Actually, bcp already has a list of things it can't figure out > automatically: > > https://github.com/boostorg/bcp/blob/develop/add_path.cpp#L195 > > which would need to be updated... ... with something like https://github.com/boostorg/bcp/commit/365e5e74f1708425ae542698730076e52acb… Unfortunately, after these fixes, everything seems to be copied correctly, but b2.exe then crashes. Something to do with `test` using `predef`, I assume, because if I delete libs/test, it then works.

1 0

Re: [boost] bcp namespace aliasing broken, impacts package providers, shared libraries unusable since 1.69
by Peter Dimov 26 May '19

26 May '19

> It could probably be changed to copy libs/$LIB/config as a special case. Actually, bcp already has a list of things it can't figure out automatically: https://github.com/boostorg/bcp/blob/develop/add_path.cpp#L195 which would need to be updated with, I assume, std::pair<fs::path, fs::path>("libs/log/build", "libs/log/config"), and std::pair<fs::path, fs::path>("libs/test/build", "libs/predef/check"), or something like that.

1 0

Re: [boost] bcp namespace aliasing broken, impacts package providers, shared libraries unusable since 1.69
by Peter Dimov 26 May '19

26 May '19

> But as a first step I think that we need to add a Travis test to tools/bcp > that exercises the scenario we want to fix. I've looked into this and we have some issues we probably need to address even before getting to namespace aliasing. 1. Since tools/boost_install and libs/headers are now needed by Jamroot, it might be better if we install them by default when `build` is requested. (libs/config is also needed by Jamroot, but almost every other library needs it as a dependency, so this usually doesn't manifest as a problem in practice.) 2. When I add them by hand, bcp installs more than needed, because tools/boost_install/test references a number of libraries such as container, log, python, and so on; we don't need these for typical uses. 3. Installing these libraries exposed issues with them: 3a. Log doesn't work because it has jamfiles in libs/log/config, which is not copied (just `build` and `src` are.) 3b. Test doesn't work because it uses predef.check in its Jamfile, but Predef is not copied. Apart from that, https://travis-ci.org/boostorg/bcp/builds/537447552

2 5

Re: [boost] bcp namespace aliasing broken, impacts package providers, shared libraries unusable since 1.69
by Peter Dimov 26 May '19

26 May '19

> Apart from that, https://travis-ci.org/boostorg/bcp/builds/537447552 After fixing the two problems in Jamroot, testing the library after --namespace still doesn't work, because libs/program_options/test/Jamfile.v2 refers to the library as boost_program_options, but it's no longer called that.

1 0

[iostreams] Interest in multithreaded lzma filter?
by Mike 26 May '19

26 May '19

Accidentally only sent this to James and not the ML: > Gesendet: Donnerstag, 23. Mai 2019 um 15:19 Uhr > Von: "James E. King III" <jking(a)apache.org> > > > On Thu, May 23, 2019 at 8:39 AM Mike via Boost <boost(a)lists.boost.org> wrote: > > > > > Gesendet: Mittwoch, 22. Mai 2019 um 23:40 Uhr > > > Von: "Jeff Bonyun via Boost" <boost(a)lists.boost.org> > > > > > > > ... How will we detect whether > > > > liblzma is capable? If it is not capable but specified, will we allow > > > > the compression anyway? > > > > > > I've been investigating this. liblzma defines a version macro, > > > LZMA_VERSION. It looks like liblzma obtained its multithreaded function > > > in 5.1.1 (in 2011). So the idea would be to branch on this macro, and > > > fall back to the currently-used single-threaded function for an older > > > liblzma version. In that case, requesting any number of threads will > > > carry out the operation, but will only use a single thread. This makes > > > it tolerant of different versions, but does mark up the code with a few > > > #if branches. I'm assuming boost goes for tolerance in this case. > > > > Does a 2019 Boost release really have to be compatible with a Pre 2011 > > release of liblzma? Is this combination even tested? > > I.e. are we sure this would be the only incompatibility? > > > > How about just adding this functionality unconditionally and see if > > someone complains? > > > > So basically if someone has an older lzma they are limited to boost > 1.70.0 or earlier. That's perhaps reasonable as long as it is > documented, but it hasn't been the typical way I have seen things > added to existing code. Well, my second question was if you are confident that 1.70 does actually work with liblzma versions older than 5.1.1? If this isn't tested, it is not supported and if it is not supported it imho makes little sense to complicate the source code to achieve potential compatibility with (what I assume to be) a very, very small number of setups. > > Another way to handle it is to keep the old path in a macro like > BOOST_IOSTREAMS_NO_MULTITHREADED_LZMA. This is common through boost. > Ideally, detecting the liblzma version from the header could then set > BOOST_IOSTREAMS_NO_MULTITHREADED_LZMA and it would always do the right > thing, but the simplest way to do it is to let the consumer of the > library set this if they need it. > Personally I'm not a fan of configuration macros when they are not absolutely necessary because it effectively means you introduce yet another variant of boost that may or may not be tested and may or may not be compatible with the variant another dependency in my project was tested with (The total configuration space of boost is already far too large for my taste). As Robert Schumacher said in his cppcon talk: It's not just about you and the user, but also every library between you and the user. All of them now either have to support both choices or have to make one choice and hope they don't become incompatible with a different 3rd party library. Yet another reason, why package & dependency management is so hard in c++. However, as long as the interface is untouched by this macro I guess it would be fine. Best Mike

3 3

Non-ASCII Path Names in Repo
by Tom Kent 25 May '19

25 May '19

In the last few days we've had a non-ASCII path name added to the repo: tools/boostdep/test/utf8-test-ßµ™∃ Which came with commit 8893d1c57951a [1] I noticed this because a python 2 script (calling shutil.copytree) I had running on windows that copied the repo around started to fail. I've long needed to update that script to python 3, and am working on this. However, I wanted to point this out to the list so we could discuss if there are any other ramifications of having a non-ascii path. I vaguely remember some discussion about something like this in the past, but couldn't find it via search. If this is already a settled topic, that's great. Tom [1] https://github.com/boostorg/boostdep/commit/8893d1c57951a4a83705ed203005576…

2 1

bcp namespace aliasing broken, impacts package providers, shared libraries unusable since 1.69
by Mathias Gaunard 25 May '19

25 May '19

Hi, I'd like to point out that bcp namespace aliasing has been broken for quite a while, which impacts package providers of Boost which choose to package it with a versioned namespace. We should try to fix to enable more people to upgrade. The bug has been reported March 2018 on trac https://svn.boost.org/trac10/ticket/13460 Then again by me this week on github https://github.com/boostorg/bcp/issues/4 Things have been made worse since 1.69 because libraries now build with visibility hidden by default, which means that with this bug symbols don't get exported and nothing links. Also I would argue that this set-up should be tested as part of the release validation process. The boost build system is arcane enough that we don't need a pretty standard build configuration to be subtly broken for more than a year. Could we try to address this before 1.71?

3 3

[iostreams] Interest in multithreaded lzma filter?
by Jeff Bonyun 23 May '19

23 May '19

I've implemented a multithreaded update to iostreams' lzma filter for my own purposes, and I was wondering if this change would be considered for including in Boost.iostreams? It uses liblzma's own multithreaded functions, so the changes to boost are actually pretty minimal. It does add a new member to the boost-provided lzma options struct -- to specify your desired number of threads -- which changes how people might use the constructor for the filter. My two biggest concerns with including it in Boost.iostreams are: - Making the filter constructor backwards compatible. Right now, users can initialize the options struct with a single unbraced int when calling the filter constructor. With the change to the struct, I want to make sure this old way still works. I.e. not requiring a braced initializer list if you only want to provide the compression level. - Handling older versions of liblzma that didn't offer multithreading. I'll work on identifying the exact versions needed, and branching on their #defined version numbers. If there is appetite for it, I can make a pull request on github. As this would be my first submission to boost, I'm sure I'll screw something up and need correcting, so be patient. Jeff

3 5

Using 'vcunk' toolset.
by Olaf van der Spek 22 May '19

22 May '19

Hi, Any chance to support 16.2 (preview 1)? ********************************************************************** ** Visual Studio 2019 Developer Command Prompt v16.2.0-pre.1.0 ** Copyright (c) 2019 Microsoft Corporation ********************************************************************** C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview>cd \vc C:\VC>cd boost_1_70_0 C:\VC\boost_1_70_0>./boost '.' is not recognized as an internal or external command, operable program or batch file. C:\VC\boost_1_70_0>./bootstrap.bat '.' is not recognized as an internal or external command, operable program or batch file. C:\VC\boost_1_70_0>bootstrap.bat Building Boost.Build engine Failed to build Boost.Build engine. Please consult bootstrap.log for further diagnostics. bootstrap.log: Found with vswhere Visual Studio Locator version 2.6.7+91f4c1d09e [query version 2.1.1046.44959] Found with vswhere Visual Studio Locator version 2.6.7+91f4c1d09e [query version 2.1.1046.44959] ### ### Using 'vcunk' toolset. ### C:\VC\boost_1_70_0\tools\build\src\engine>if exist bootstrap rd /S /Q bootstrap C:\VC\boost_1_70_0\tools\build\src\engine>md bootstrap C:\VC\boost_1_70_0\tools\build\src\engine>cl /nologo /RTC1 /Zi /MTd /Fobootstrap/ /Fdbootstrap/ -DNT -DYYDEBUG -wd4996 kernel32.lib advapi32.lib user32.lib /Febootstrap\jam0 command.c compile.c constants.c debug.c execcmd.c execnt.c filent.c frames.c function.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c object.c option.c output.c parse.c pathnt.c pathsys.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c md5.c class.c cwd.c w32_getreg.c native.c modules/set.c modules/path.c modules/regex.c modules/property-set.c modules/sequence.c modules/order.c command.c compile.c constants.c debug.c execcmd.c execnt.c filent.c frames.c function.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c object.c Generating Code... Compiling... option.c output.c parse.c pathnt.c pathsys.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c md5.c class.c cwd.c w32_getreg.c Generating Code... Compiling... native.c set.c path.c regex.c property-set.c sequence.c order.c Generating Code... C:\VC\boost_1_70_0\tools\build\src\engine>.\bootstrap\jam0 -f build.jam --toolset=vcunk "--toolset-root=Visual Studio Locator version 2.6.7+91f4c1d09e [query version 2.1.1046.44959]\Common7\Tools\..\..\VC\ " clean ### ### Unknown toolset: vcunk ### ### Known toolsets are: acc, borland, cc, como, clang, darwin, gcc, gcc-nocygwin, intel-darwin, intel-linux, intel-win32, kcc, kylix, metrowerks, mipspro, msvc, qcc, pathscale, pgi, sun, sunpro, tru64cxx, vacpp, xlcpp, vc7, vc8, vc9, vc10, vc11, vc12, vc14, vc141, vc142, vmsdecc ### C:\VC\boost_1_70_0\tools\build\src\engine>.\bootstrap\jam0 -f build.jam --toolset=vcunk "--toolset-root=Visual Studio Locator version 2.6.7+91f4c1d09e [query version 2.1.1046.44959]\Common7\Tools\..\..\VC\ " ### ### Unknown toolset: vcunk ### ### Known toolsets are: acc, borland, cc, como, clang, darwin, gcc, gcc-nocygwin, intel-darwin, intel-linux, intel-win32, kcc, kylix, metrowerks, mipspro, msvc, qcc, pathscale, pgi, sun, sunpro, tru64cxx, vacpp, xlcpp, vc7, vc8, vc9, vc10, vc11, vc12, vc14, vc141, vc142, vmsdecc ### C:\VC\boost_1_70_0\tools\build\src\engine>exit /b 1 -- Olaf

1 0

[config] Disabling symbol visibility?
by John Maddock 19 May '19

19 May '19

We have an open ticket from someone that wants all symbols hidden, including those marked with BOOST_SYMBOL_VISIBLE, is this sensible to support? What are the likely consequences of doing so? See https://github.com/boostorg/config/issues/243 Thanks in advance, John. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

3 2

[gsoc19] Introduction
by Thomas Ferrand 18 May '19

18 May '19

Hello everyone, I am Thomas Ferrand a french student in computer science and I am happy to take part in GSoC this summer. I will be working on Boost.SafeFloat (https://github.com/sdavtaker/safefloat) a library that aims at helping developers detecting errors in floating point numbers computations. Best regards, Thomas Ferrand

3 2

[GSoC19] Greetings
by Kim 18 May '19

18 May '19

Hello, Another student and I will be contributing to the proposed Boost library, Real, with mentors Damian Vicino and Laouen Belloli. My name is Kimberly Swanson. I am a mathematics undergrad at University of Central Florida. My primary focus during the summer will be to improve the memory complexity of Real's internal representation. After the main changes, I plan to implement benchmarks with Google Benchmark (though I am open to using other libraries, if recommended). Future changes made regarding memory/computational complexity would refer to results from the benchmark. I aim to get it to a review-ready state before the end of GSoC (fingers crossed). Warm Regards, Kim

2 1

[variant2] Acceptance conditions met - Targeted for 1.71.0
by Michael Caisse 17 May '19

17 May '19

Peter Dimov has updated the Variant2 library based on review acceptance criteria. I have reviewed the changes and "OK" Variant2 to be included as a Boost library. My understanding is that Peter is targeting Variant2 to be available in the 1.71.0 release. Congratulations Peter! Thank you for your quick work in updating the library based on the review feedback. -- Michael Caisse Ciere Consulting ciere.com

2 1

Need help setting up Travis CI and codecov
by Sagnik Dey 15 May '19

15 May '19

We are getting ready to start work on the Boost.Real project and getting Travis CI and codecov integration for the new repository https://github.com/BoostGSoC19/Real, would be a great help. Can someone please provide some help as to how to set it up? The yml files for both travis and codecov are already present in the repo as this is a fork from an older repo that had a working travis and codecov integration. Thank You, Sagnik Dey

2 1

[GSOC19] Introduction
by Ashar 15 May '19

15 May '19

Hi, My name is Mohammad Ashar Khan, I will be working on uBLAS to bring better expression templates support using boost.YAP. I will also be adding support for expression optimization using mathematical laws. Regards Mohammad Ashar Khan

1 0

[Real] [GSoC19] Working together on Real
by Kim 15 May '19

15 May '19

Hello, Sagnik Dey and I, both GSoC19 students, will work together on Real. Laouen Belloli suggested we reach out to the dev list regarding how we will work with the BoostGSoC19/Real repo. Should we 1. work on the same repo using different branches, or 2. each make a fork of the repo We have some overlapping tasks from our GSoC proposals, and plan on possibly implementing different implementations for some thing(s), while dividing up the tasks between ourselves for others. Further, we would like to get Travis CI and codecov in the respective repo(s), but we need to know which option we're going with first. Best Regards, Kim

1 0

[GSOC19] Introduction
by Amit Singh 15 May '19

15 May '19

Hello everyone, My name is Amit Singh. I will be contributing to ublas tensor this summer. My goal is to improve the design and integrating new features to tensor. Best Regards Amit Singh

1 0

Re: [boost] [ Interest? ] [ out_ptr ] Tiny C++ Abstraction for C-Style Output Pointers
by Bjorn Reese 12 May '19

12 May '19

On 06/28/18 21:03, ThePhD via Boost wrote: > out_ptr is a small abstraction for making types such as > std::unique_ptr, std::shared_ptr, boost::shared_ptr, and the upcoming > std::retain_ptr > <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0468r0.html> work > work C-Style output functions as a parameter, addressing the need of > wanting to be able to do "my_c_api_init( foo, bar, &my_smart_ptr );". It's Does out_ptr have other use-cases than C interoperability?

7 14

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

11 May '19

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

7 6

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

10 May '19

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

14 63

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

09 May '19

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

1 0

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

08 May '19

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

1 0

Re: [boost] [doc][signals] Broken links for Boost 1.70
by Glen Fernandes 08 May '19

08 May '19

On 2019-04-15 at 21:46:18 Mateusz Loskot wrote: > On https://www.boost.org/doc/libs/1_70_0/ links to these documentations are broken: > > https://www.boost.org/doc/libs/1_70_0/libs/signals/ > > Could anyone help to identify what is going wrong with those and how to fix it? Signals was removed as a Boost library starting with in 1.69.0 and I had put a notice in the 1.69 release notes about this (section "Discontinued Libraries"). I've removed the links for Signals (v1) on the Libraries page going forward. e.g. https://www.boost.org/doc/libs/develop/libs/libraries.htm e.g. https://www.boost.org/doc/libs/develop/ Additionally, I've added an entry in the "Libraries Retired from Boost" on that first libraries page for Signals (v1) alongside compose. Glen

2 1

[any] ABI break
by Antony Polukhin 07 May '19

07 May '19

Hi, I'm planning to apply an ABI breaking change to the Boost.Any https://github.com/boostorg/any/pull/11 That PR makes the binaries that use boost::any smaller. For example libboost_program_options.so looses 4KB in size. Boost libraries were not guaranteeing ABI stability, but boost::any is quite often used across library boundaries. Double checking that there's no objections.

1 1

Lets do 1.70.1 WHO IS WITH ME!!!
by Vinnie Falco 06 May '19

06 May '19

A crashing defect in Beast was discovered shortly after release: <https://github.com/boostorg/beast/issues/1599> It happens under high load when things happen at just the right time (or wrong time depending on how you look at it). It *will* eventually happen to any long-lived connection that sees enough traffic and timeouts. The fix is trivial: <https://github.com/vinniefalco/beast/commit/8620439f8e38db62713cff55a428bf8…> Thanks to the detailed report we were able to write a unit test which reproduces it reliably. Is this worth putting up a 1.70.1 for? The timeout feature is new in 1.70 and it is rather a shame that people might not be able to use it because of a defect. Regards

8 19

b2 --layout=versioned compiler tag in library filename
by Paul Harris 06 May '19

06 May '19

Hi guys, In the past, b2 would build libraries named like so: libboost_atomic-gcc48-mt-d-1_60.so (note -gcc48-) I tried compiling Boost 1.66.0 (from boost-git) with gcc 8.3.0, but the library it generates is named: libboost_atomic-gcc-mt-d-x64-1_66.so (note the -gcc-) No compiler version number in the tag... I (and CMake) was expecting it to be named: libboost_atomic-gcc83-mt-d-x64-1_66.so (note the -gcc83-) To build, I did: ./bootstrap.sh --with-libraries="atomic" ./b2 --layout=versioned I then downloaded the 1.70.0 tarball and compiled that, and this time the result was: tar xfv boost_1_70_0.tar.bz2 cd boost_1_70_0/ ./bootstrap.sh --with-libraries="atomic" ./b2 --layout=versioned ls -l stage/lib libboost_atomic-gcc8-mt-d-x64-1_70.so I don't see any documentation around the compiler version tag, what is the current policy? thanks, Paul

5 7

[thread] compiler error gcc 7.3 on cygwin
by James E. King III 06 May '19

06 May '19

Getting an internal compiler error with gcc 7.3 but only on cygwin 64-bit. Jim@pulsar /cygdrive/c/boost/libs/thread $ ../../b2 --abbreviate-paths toolset=gcc cxxstd=11 define=_POSIX_C_SOURCE=200112L define=__USE_ISOC99 threadapi=pthread address-model=64 variant=release -q ... gcc.compile.c++ ../../bin.v2/libs/thread/test/test_10963_c.test/gcc-7.3.0/rls/cxstd-11-iso/thrd-mlt/vsblt-hdn/test_10963_c.o In file included from ../../boost/thread/detail/invoker.hpp:30:0, from ../../boost/thread/future.hpp:31, from ../../libs/thread/test/test_10963.cpp:13: ../../boost/thread/detail/invoke.hpp: In function ‘decltype (*(forward<A0>)(boost::detail::invoke::a0).*boost::detail::invoke::f) boost::detail::invoke(Fp&&, A0&&) [with Fp = void (boost::executors::basic_thread_pool::*)(); A0 = boost::executors::basic_thread_pool*]’: ../../boost/thread/detail/invoke.hpp:102:43: internal compiler error: in gimplify_expr, at gimplify.c:12006 return (*boost::forward<A0>(a0)).*f; ^ Please submit a full bug report, with preprocessed source if appropriate. See <https://gcc.gnu.org/bugs/> for instructions. "g++" -std=c++11 -fvisibility-inlines-hidden -m64 -mthreads -O3 -finline-functions -Wno-inline -Wall -pedantic -fvisibility=hidden -Wextra -Wno-long-long -Wno-unused-parameter -Wunused-function -pedantic -DBOOST_ALL_NO_LIB=1 -DBOOST_THREAD_THROW_IF_PRECONDITION_NOT_SATISFIED -DNDEBUG -D_POSIX_C_SOURCE=200112L -D__USE_ISOC99 -I"../.." -c -o "../../bin.v2/libs/thread/test/test_10963_c.test/gcc-7.3.0/rls/cxstd-11-iso/thrd-mlt/vsblt-hdn/test_10963_c.o" "../../libs/thread/test/test_10963.cpp" ...failed gcc.compile.c++ ../../bin.v2/libs/thread/test/test_10963_c.test/gcc-7.3.0/rls/cxstd-11-iso/thrd-mlt/vsblt-hdn/test_10963_c.o... If I change the C++ language level to 03 the problem goes away. I also cannot reproduce it on linux with the same version of compiler (but it probably isn't the exact same compiler code). Should I go ahead and file that gcc bug? - Jim

2 1

[boost-ci] Extended list of branches allowed to build
by Mateusz Loskot 03 May '19

03 May '19

Hi, This is to inform maintainers and contributors about little proposal I made to the common CI infrastructure maintained by James https://github.com/boostorg/boost-ci/pull/11 The comments should explain rationale behind extending the common naming convention to enable CI builds for topic branches (w/o changing branch filters in .travis.yml etc.). The PR has now been merged. I'd like to encourage mainainers who use the boost-ci setup to pull the update into the libraries. It may also be helpful to put a note in CONTRIBUTING.md or README.md to let contributors know that if they wish to test their contributions on their own CI accounts prior submitting it as PR, they should name their topic branches with prefixes: feature/*, fix/* or pr/* I hope this simple change to boost-ci would be adopted by across Boost libraries and make some contributors' life esier. "What would be great for one off contributors like me is if all CI scripts would support testing of feature branches in forked repositories by default." - from #boost at cpplang.slack.com Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Fingerprint=C081 EA1B 4AFB 7C19 38BA 9C88 928D 7C2A BB2A C1F2

1 0

[graph] Plans to upgrade algorithms with Boost.Parameter named arguments
by Cromwell Enage 03 May '19

03 May '19

Hello, everyone! With the most significant changes to Boost.Parameter now in both the 'master' and 'develop' branches, one of my next major goals is to prepare a pull request to incorporate Boost.Parameter named arguments into Boost.Graph algorithms that currently use bgl_named_params. My personal fork, <https://github.com/CromwellEnage/graph>, has a working version of such algorithms. However, I'd like your feedback on how to upgrade the corresponding documentation. I have a rough draft for documenting the Boost.Parameter-enabled A* algorithms here for your review: < https://github.com/CromwellEnage/graph/blob/develop/doc/astar_search.html>. Please suggest improvements or state if you are sufficiently satisfied with its current form to be able to use the A* algorithms with Boost.Parameter named arguments. I plan to use the same documentation style for the other affected algorithms. Regards, Cromwell D. Enage

1 0

[disjoint_sets] content moved into boostorg/graph
by James E. King III 02 May '19

02 May '19

The CMT was maintaining a standalone repository for one class, disjoint_sets, of which the only internal boost usage was in graph and graph_parallel (which depends on graph). disjoint_sets has been moved into boostorg/graph on develop. The superproject has a PR to remove it as a submodule, and the boostdep tools has a PR to remove it from an exclusion list. The path to the header has been preserved, so external usage will remain unaffected for those who download boost as a package, as disjoint_sets is header-only. If you experience any issues on develop relating to the header boost/pending/disjoint_sets.hpp, make sure you have the latest boostorg/graph, and you can manually remove libs/disjoint_sets from your sandbox, that should resolve it until the other PR in the superproject comes along. Even after that is merged, I'm not sure how the defunct disjoint_sets will be handled in sandboxes and may still need to be manually removed. There is no useful content in disjoint_sets at this point. I had experienced some complaints from b2 about being unable to link the header because it was coming from the old repository when I staged this change. Thanks, Jim

2 1

[variant] Heads-up!
by Antony Polukhin 02 May '19

02 May '19

Hi, I've merged a very cool optimization by Nikita Kniazev into the master branch. From now on boost::variant does pointer stealing for recursive variants. This significantly improves the performance of the variants move constructors. However if you use a variant variable after the std::move for anything except destruction and assignment then you're getting an UB. Beware! -- Best regards, Antony Polukhin

9 25