- Boost - lists.preview.boost.org

[boostrap.bat] compilation error
by Raffi Enficiaud 16 Jun '19

16 Jun '19

I have the following during the compilation of bootsrap/b2: d:\bamboo_build_dir\rs-bcb233-vc2008win\library\tools\build\src\engine\sysinfo.h(41) : error C2864: 'b2::system_info::cpu_core_count_' : only static const integral data members can be initialized within a class d:\bamboo_build_dir\rs-bcb233-vc2008win\library\tools\build\src\engine\sysinfo.h(42) : error C2864: 'b2::system_info::cpu_thread_count_' : only static const integral data members can be initialized within a class Current develop (yesterday), Raffi

2 1

[Range] pr for bug in any_range / development/maintenance status
by Max Jendruk 14 Jun '19

14 Jun '19

Hello everyone, I submitted a bugfix on Github about a month ago that fixes an issue where passing a (non-reference) value type as Reference parameter to any_range could lead to undefined behaviour. The issue has been known for a while (5 years). I would like to know when I can expect this to be merged. Also, is there a general review cycle that I'm not aware of? There are still a couple of other pull requests open, some of which were opened over a year ago. Just by looking at the activity on Github, it's difficult to determined how actively Boost.Range is still being maintained. What is the development/maintenance status of the library? I'm wondering whether it would be worth the time implementing a few more adaptors similar to those in the C++20 standard like take_view, join_view, and all_view, which I'd be happy to do. Are additions to the library still being accepted at this point? Best regards, Max

3 2

[regression tests] Regression test pages not updating since June 4th
by Joaquin M López Muñoz 11 Jun '19

11 Jun '19

Thank you, Joaquín M López Muñoz

1 0

[out_ptr] Review scheduled for June 16 to June 26
by Zach Laine 10 Jun '19

10 Jun '19

This is a heads-up that out_ptr has been scheduled for review, starting next Sunday, June 16. From JenHeyd's earlier post about the library: " Documentation: https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr.adoc Repository: https://github.com/ThePhD/out_ptr <https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr.adoc> Standards Proposal: https://thephd.github.io/vendor/future_cxx/papers/d1132.html 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 for more details). " Please consider checking out the library now, and doing a review next week. It's a pretty small library; reviews should be pretty quick to do. Zach

1 0

Re: [boost] [Boost.Stringify] Yet another formatting library.
by Roberto Hinz 09 Jun '19

09 Jun '19

On Sat, Jun 8, 2019 at 9:53 AM Helmut Zeisel <HZ2012(a)gmx.at> wrote: > Actually I did not check your library, but I would be interested in a > formatting library that is not based on functions, but on function objects. > > The usage would not be something like > > std::string s1 = to_string("base10", 15); > std::string s2 = to_string("base16", 42); > > but > > stringifier dec; > dec.set_base(10); > std::string s1=hex(15); > stringifier hex; > hex.set_base(16); > std::string s2=hex(42); > > To format values in Boost.Stringify, one does like this, for example: namespace strf = boost::stringify; int v = 255; std::string s = strf::to_string(v, " in hexadecimal is ", strf::hex(v)); assert(s == "255 in hexadecimal is ff"); So could maybe lambdas solve your need ? auto hex = [](int v){return strf::to_string(strf::hex(v)); }; auto dec = [](int v){return strf::to_string(v); }; auto s1 = hex(15); auto s2 = dec(42); assert(s1 == "f"); assert(s2 == "42"); > With a function object based interface, one could easily store and reuse > different formating options in parallel. > Not clear to me what you mean by that. Could you explain better ?

2 2

[Boost.Stringify] Yet another formatting library.
by Roberto Hinz 08 Jun '19

08 Jun '19

Dear Boost Community, Naturally, any interest in a new formatting library must be lower now that fmtlib is approved into C++20. Still, I'm confident that the library I'm working on has great potential, so I would like to know your opinions. https://github.com/robhz786/stringify This is a locale-independent formatting library that: - has great performance ( almost twice as fast as fmtlib ) - can do things that others can't, like encoding conversion. - is highly customizable. Through "facets" you can specify things like numeric punctuation, encoding error handling, and the width calculation algorithm. - is highly extensible. Not only you can add new input types with own formatting options and facets, but also easily add new output types. The doc has an example of how to extend the library to write to QString ( from Qt ). Actually, I did announce this library about two years ago. But the design is much enhanced now. I believe it will be ready for review by the end of this year. But it may take longer. I much appreciate any feedback. Thank you. Roberto

2 2

Setting up linter for boost library development
by Sagnik Dey 07 Jun '19

07 Jun '19

If someone has a linter setup with appropriate settings, can you please share details? I'm working on Boost.Real and would like to have a linter to help with coding style consistency. Help is appreciated. Thank You

2 1

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

06 Jun '19

> > >Are there instructions for developers that I've missed? > > There are some instructions here: > > > https://www.boost.org/doc/libs/1_70_0/libs/config/doc/html/boost_config/gui… > > Thanks! I was expecting developer guidelines in the github readme, not in the actual library docs! doh! I have made a PR #285 and after some trial and error (I only have VS2015 and VS2017 available to test locally) I think I have something. However, in my test I throw and catch exceptions: int test() { std::exception_ptr ep; try { throw 42; } catch(...) { ep = std::current_exception(); } try { std::rethrow_exception(ep); } catch(int i) { // return zero on success return i == 42 ? 0 : 1; } return 1; } But the CI jobs have gcc and clang configured to compile without exception support! And I get errors like: libs/config/test/boost_no_cxx11_hdr_exception.ipp:22:5: error: cannot use 'throw' with exceptions disabled throw 42; ^ libs/config/test/boost_no_cxx11_hdr_exception.ipp:20:3: error: cannot use 'try' with exceptions disabled try ^ I have two questions: 1) Where are exceptions disabled in the CI jobs? I can't find it in the .travis.yml, but I can see e.g. clang being invoked with -fno-exceptions 2) How can I test proper support for std::current_exception() and std::rethrow_exception() if exceptions are disabled for the test? Thanks!

2 1

[ 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