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 30 May '19

30 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