- Boost - lists.preview.boost.org

Requesting endorsements of Boost.STLInterfaces for review
by Zach Laine 20 Sep '19

20 Sep '19

As mentioned a couple of weeks ago, I started a small library that was an updated iterator_facade. It is now a still-smallish library called stl_interfaces that includes a pre-C++20 implementation of view_interface, and analogous templates iterator_interface (a cross between Boost.Iterator's iterator_facade and iterator_adaptor), and container_interface. Each of these makes it easier to write a view, iterator, or container, respectively. Using container_interface, I was able to write a version of static_vector in which I implemented only 21 member functions, and the template provided the other 40(!) functions. The library is C++14 and later. There is an inline v1 namespace for the C++14 implementations, and an experimental non-inline v2 namespace with implementations using C++20 standard concepts. The part using C++20 concepts requires GCC 8 or 9, and cmcstl2 (more info on that on the Github page). Github page: https://github.com/tzlaine/stl_interfaces Online docs: https://tzlaine.github.io/stl_inteTherfaces/doc/html/index.html <https://tzlaine.github.io/stl_interfaces/doc/html/index.html> Oh, and if you're willing to act as review manager, please let me know. Zach

9 17

[GitHub] Checks not listed for Travis CI
by Mateusz Loskot 18 Sep '19

18 Sep '19

Hi, GitHub offers the Checks tab [1] which displays CI checks based on Travis CI, Azure Pipelines, etc. I can't find out why the Travis CI ones are not displayed for any of repositories under github.com/boostorg/ I checked Histogram, Beast, and a few others and ffor GIL only Azure Pipelines is displayed (I integrated AzP there from the marketplace fairly recently). I suspect, that is due to the fact Travis CI integration was installed long time ago, using an old way, so it does not 'recognise' new features. For example, using the old webhooks/services method now deprecated which then was automatically ported to new marketplace-based integrations. Does anyone know how to add the Checks feature to boostorg/ repos? One of interesting feature of it is that it can display "a specific line in a commit causes a check to fail" [1] [1] https://help.github.com/en/articles/about-status-checks#checks Here is example of the Checks in full: https://github.com/OSGeo/gdal/pull/1776/checks I can confirm enabling the Checks has nothing to do with the branch protection feature and enabling required statuses of PRs. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 2

Details of environment building release docs and website
by Mateusz Loskot 18 Sep '19

18 Sep '19

Hi, Where can I find details about the environment used to build the website and the documentation for the releases? For example, - What is the OS? (i.e. system packages can be identified then) - What is toolset and compiler version used? GCC 4.8? - What is the version of Python, Doxygen, AsciiDoc, Sphinx? I looked at these places, but it's still unclear to me https://www.boost.org/development/website_updating.html https://github.com/boostorg/website/blob/master/.travis.yml Or was I supposed to derive the answer from the Travis CI's image php:'5.3'? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

[Quickbook] VSCode Extension for syntax colouring & simple preview
by Jan Bouwer 18 Sep '19

18 Sep '19

I've built a Visual Studio Code <https://code.visualstudio.com/> extension to provide simple syntax colouring & preview generation for Boost.Quickbook source files. It is available from within the VSCode extension marketplace or at https://marketplace.visualstudio.com/items?itemName=JBouwer.boost-quickbook… - from where the GitHub repos/issue tracker can be accessed too. Perhaps somebody else may find this useful too - like I have. Regards Jan Bouwer

2 1

[program_options] Proposal: self-contained, header-only port of Boost Program Options library
by Vicram Rajagopalan 17 Sep '19

17 Sep '19

I am interested in creating a header-only implementation of the Boost Program Options library that only depends on the C++ standard library. Program Options uses several other Boost libraries, so I would have to re-implement some of it using standard library constructs. I have 2 questions for the community: 1. Would you use something like this if it were available? 2. Do you know of any implementation details of Program Options which might make some part of this difficult or impossible? To be clear, I do not intend for this to be merged into Boost in any form. Rationale: There is no portable command-line argument-parsing capability in the C++ standard library. There's getopt, but that's in unistd.h which is only available on Unix-based systems. The only widely-used C++ command-line parsing library I am aware of is Program Options, but that requires adding a dependency on Boost to your project, which seems like overkill to me. I would like to be able to simply add a project as a submodule in my Git repo and #include it without even having to add anything to my build files. The goal is to ensure that the library is as portable and easy to include as possible, because it shouldn't be difficult to parse command-line options. I appreciate any thoughts, comments, or criticisms! -Vicram Rajagopalan

9 14

[Boost.numeric.ublas] Compiler warnings when building with O2 optimizations and NDEBUG defined
by Albert Perlman 17 Sep '19

17 Sep '19

I am using boost v1.69, compiling with g++-7 for an x86 target. If I build with -O2 optimization flags when NDEBUG is defined, I get the following compiler warning: ./../boost/numeric/ublas/matrix_expression.hpp:59:20: error: ‘*((void*)&<anonymous> +8)’ is used uninitialized in this function [-Werror=uninitialized] return e_.size2 (); If I add -fno-partial-inling to the compiler flags, this makes the warning go away. This warning does not appear if NDEBUG is not defined, regardless of optimization flags. This behavior is the same with boost v1.71. I would like to build with the -fpartial-inling optimization when NDEBUG is defined. Is there a workaround to fix this warning? -- Albert -- IMPORTANT: The information contained in this transmission may be privileged, proprietary and confidential and protected from disclosure. It is intended only for the intended recipient. If you are not the intended recipient or a person responsible for delivering this transmission to the intended recipient, you may not disclose, copy or distribute this transmission or take any action in reliance on it. If you received this transmission in error, please notify us immediately by replying to this message and please dispose of and delete this transmission. Thank you. Yaskawa America, Inc.

1 0

Write data to NAND flash file system
by JH 13 Sep '19

13 Sep '19

Hi, I am using boost::filesystem to write / remove files to NAND flash file system where it writes by pages, the system can cache and pack data upon write back to avoid segmentation if fsync(), fdatasync(), O_SYNC or a sync mounted filesystem are not used to force write. Will the boost::filesystem::ofstream and operator<< involve any of sync call? Which IO library is not using sync call? Thank you. Kind regards, - jupiter

1 0

math
by Gero Peterhoff 12 Sep '19

12 Sep '19

Hello Developers, Hello John, thanks for making the float128_t features I missed available in boost 1.71. But: - I miss in boost::math::constants log2_e (M_LOG2E); You have written in the documentation that all constants are now available; are there any other constants missing? - in boost/multiprecision/float128.hpp, the value in numeric_limits<float128_t>::is_bounded must be true Thanks and Greetings Gero

2 1

Secure-by-default networking
by Alex Christensen 11 Sep '19

11 Sep '19

At https://github.com/boostorg/asio/pull/283 <https://github.com/boostorg/asio/pull/283> I’ve attached a proof-of-concept which explores making ASIO secure by default. The C++ committee is discussing what secure-by-default networking would look like in the soon to be published papers P1860 and P1861. Since the C++ Networking TS is based on ASIO, this seems like a good place to try things out. The implementation uses BoringSSL for its crypto and Security.framework to evaluate certificates against the root certificates trusted by the system. I've implemented enough to see what the API shape would need to be, and it works with basic client and server programs. I’d love to get your feedback on this initial work, including any implementation concerns you have and suggestions on portability. I don’t think the patch is ready to commit as-is.

3 2

Re: [boost] Secure-by-default networking
by Bjorn Reese 11 Sep '19

11 Sep '19

On 9/11/19 1:35 AM, Alex Christensen via Boost wrote: > At https://github.com/boostorg/asio/pull/283 <https://github.com/boostorg/asio/pull/283> I’ve attached a proof-of-concept which explores making ASIO secure by default. The C++ committee is discussing what secure-by-default networking would look like in the soon to be published papers P1860 and P1861. Since the C++ Networking TS is based on ASIO, this seems like a good place to try things out. Please don't. There are plenty of networking applications that do not use SSL. Use ssl::stream if you want secure-by-default.

1 0

Re: [boost] Requesting opinions on CECS (C/C++ Error Control) library for possible boost implementation.
by Bjorn Reese 11 Sep '19

11 Sep '19

On 9/8/19 3:17 PM, Terablade via Boost wrote: > I have also released the library on github:https://github.com/terablade2001/CECS This library is described as handling "textual informative error control" using severity levels, so the first question that comes to mind is how this differs from Boost.Log? PS: The standard as reserved all symbol names starting with an underscore followed by a capital letter.

2 1

[Random] Proposal: Faster RANLUX engines
by Christoph Conrads 10 Sep '19

10 Sep '19

Boost.Random and the C++11 standard library ship with a 24- and a 48-bit RANLUX pseudo-random number generator (PRNG). I propose to add 32- and 64-bit RANLUX PRNGs because they are at least 40% faster. Additionally, the 32-bit RANLUX PRNG can be implemented as follows: #include <boost/cstdint.hpp> #include <boost/random.hpp> namespace br = boost::random; typedef br::subtract_with_carry_engine<boost::uint32_t,32,3,17> ranlux32_base; typedef br::discard_block_engine<ranlux32_base, 389, 16> ranlux32; There is C++98 benchmark code at the end of this e-mail requiring only Boost and a C++ compiler. Below I will briefly discuss the theory behind RANLUX PRNGs, where the new generators are coming from, and why the 64-bit RANLUX PRNG requires (a few lines of) new code. Drawing from RANLUX PRNGs is a two-step process. In the first step a value is drawn from a "subtract-with-borrow" (SWB) generator implementing b-bit modular arithmetic [1]. Then, values are generously discarded yielding uniformly distributed values (uniform in a dynamical systems model) [2]. The RANLUX PRNGs using 24- and 48-bit arithmetic always gave me an itch so I looked into the motivation behind this. It turns out [3] that this restriction arose likely from a) computational limitations in the 1990s and b) Lüscher's interest in the generation of floating-point numbers (single-precision floating-point numbers have 24-bit significand). SWB PRNGs come in two flavors (Type I, Type II) and they make use of three parameters called base b, short lag s, and long lag r. Using modern prime factorization methods, one can quickly come up with the 32-bit PRNG above, a Type I SWB generator with b=2^32, r=17, and s=3. This one can be implemented as shown above. To generate 64-bit values, one should use a Type II SWB with b=2^64, r=62, and s=5 (all other 64-bit generators with b=2^64 and r < 100 will be awfully slow). What distinguishes the different types of SWBs is the recurrence for the computation of variates. For Type I it is x_n := (x_{n-s} - x_{n-r} + c_n) mod b, where c_n is a carry bit. For Type II it is x_n := (x_{n-r} - x_{n-s} + c_n) mod b. (Observe the order of long lang and short lag in these formulas.) Type II SWBs are not difficult to implement but it requires either a modification of `subtract_with_carry_engine` or a new class. Let me know what you think about this proposal. Christoph Conrads [1] G. Marsaglia, A. Zaman: "A New Class of Random Number Generators". 1991. URL: https://www.jstor.org/stable/2959748 [2] Martin Lüscher: "A Portable High-Quality Random Number Generator for Lattice Field Theory Simulations". 1994. URL: https://arxiv.org/abs/hep-lat/9309020 [3] Christoph Conrads: "Faster RANLUX Pseudo-Random Number Generators". 2019. URL: https://christoph-conrads.name/faster-ranlux-pseudo-random-number-generators // Build with: // c++ -Wextra -Wall -std=c++98 -pedantic benchmark.cpp -O3 \ // -march=native -DNDEBUG -lboost_chrono -lboost_system #include <boost/chrono.hpp> #include <boost/cstdint.hpp> #include <boost/random.hpp> #include <cassert> #include <cstdio> #include <limits> #include <string> namespace chrono = boost::chrono; typedef chrono::milliseconds milliseconds; typedef chrono::process_cpu_clock my_clock; namespace br = boost::random; typedef br::subtract_with_carry_engine<boost::uint32_t,32,3,17> ranlux32_base; typedef br::discard_block_engine<ranlux32_base, 389, 16> ranlux32; struct dummy_engine { typedef boost::uint32_t result_type; static result_type max() { return std::numeric_limits<result_type>::max(); } static result_type min() { return std::numeric_limits<result_type>::min(); } result_type operator() (); result_type state_; }; dummy_engine::result_type dummy_engine::operator() () { return state_++; } std::string get_name(const dummy_engine&) { return "dummy-prng"; } std::string get_name(const br::ranlux24&) { return "ranlux24"; } std::string get_name(const br::ranlux48&) { return "ranlux48"; } std::string get_name(const ranlux32&) { return "ranlux32";} template<typename Generator> typename Generator::result_type draw(Generator& gen) __attribute__((noinline)); template<typename Generator> typename Generator::result_type draw(Generator& gen) { return gen(); } template<typename Generator> void run(boost::uintmax_t num_draws) { assert(Generator::min() == 0); unsigned w = Generator::max() == std::numeric_limits<boost::uint64_t>::max()?8u: Generator::max() == (UINTMAX_C(1)<<48) - 1u ?6u: Generator::max() == std::numeric_limits<boost::uint32_t>::max()?4u: Generator::max() == (UINTMAX_C(1)<<24) - 1u ?3u: Generator::max() == std::numeric_limits<boost::uint16_t>::max()?2u: Generator::max() == std::numeric_limits<boost::uint8_t>::max() ?1u: 0u ; Generator gen; my_clock::time_point t_0 = my_clock::now(); for(uintmax_t i = 0; i < num_draws; ++i) draw(gen); my_clock::time_point t_1 = my_clock::now(); milliseconds t_ms = chrono::duration_cast<milliseconds>(t_1 - t_0); double bytes_per_sec = w * num_draws * 1000u/double(t_ms.count()); std::string name = get_name(gen); boost::uint16_t dummy = boost::uint16_t(gen()); std::printf( "%-26s | %10lu | %20.2e | %hu\n", name.c_str(), t_ms.count(), bytes_per_sec, dummy ); } int main() { boost::uintmax_t num_draws = UINTMAX_C(100000000); run<dummy_engine>(num_draws); run<br::ranlux24>(num_draws); run<ranlux32>(num_draws); run<br::ranlux48>(num_draws); }

1 0

Interest in circular span?
by Bjorn Reese 10 Sep '19

10 Sep '19

I am working on a circular queue library that contains a non-owning circular span, a fixed-sized circular array, and a dynamically resizable circular vector. Would you be interested in adding such a library to Boost? The design is inspired by Boost.CircularBuffer, std::span, and P0059R4 std::experimental::ring_span. The code can be found at: https://github.com/breese/trial.circular The documentation can be found at: https://github.com/breese/trial.circular/tree/develop/doc circular::span can be used to implement the P0059R4 ring_span, as shown in one of the example: https://github.com/breese/trial.circular/blob/develop/example/p0059/ring_sp… circular::span can also be used to implement most parts of boost::circular_buffer; all except insertions and erasure at arbitrary positions.

7 10

[Intrusive] Movable intrusive container elements?
by Phil Endecott 09 Sep '19

09 Sep '19

Dear Experts, Is it possible to make intrusive container elements movable? Here's the scenario. Say I have struct Thing { int id, string name }; and I want a container of those indexed by both the id and the name. Using Boost.Intrusive I can add two hooks to the struct and have two intrusive::sets, one using id as the key and the other using name. All good. But say my ids are a contiguous range of integers starting at zero. It would be much better to store the Things in a vector (or similar), indexed by the id, and use Intrusive only for the name index. Or if my ids are not contiguous, I might still prefer to keep the things in a vector sorted by id and do id lookup by binary search (i.e. a flat_set). In both cases, the issue is that when the vector expands or is sorted the elements are moved, and this will invalidate the pointers used for the name index. Is is possible to fix this using move constructors and move assignment for the hooks? I.e. those operations could adjust the pointers pointing to the element's old location to point to its new location. (This has some similarities to how auto-unlink hooks already fix pointers to remove the being-deleted item.) Maybe there is some complication that makes this impossible. Or maybe this is already possible?? Any thoughts anyone? Regards, Phil.

2 2

Requesting opinions on CECS (C/C++ Error Control) library for possible boost implementation.
by Terablade 08 Sep '19

08 Sep '19

Hi all. Recently I focused on completing and releasing a public a C/C++ library for C/C++ Error Control System. I've exposed the library to public via two articles in Linked In, and especially in the "C++ Developers Groups" were I got some positive feedback (a few comments and likes). A "Senior Architect at Apple" left the following comment: "Man that’s error traceability for a lot of readability". This made me wonder if this library deserves to be exposed more to C/C++ developers, and led me to think of boost library. Personally I'm testing the library by integrating it in different projects, and I'm quite happy from the outcome. With very few code (increased readability) and a specific design approach for capturing and handling possible errors, it does provide a lot of customized error traceability - a feature which for me is quite important on complex projects and especially when multiple libraries mix up and need integrated error tracking through all of them. Reading the boost guidelines I joined this mailing list to request review and opinions.As my free time is a a bit limited to convert and test the library to be supported by boost, I'd like some comments and review first.Do you believe that CECS could be a useful util for Boost? Should I go for it? The two articles in that group (requires membership) is at:https://www.linkedin.com/feed/update/urn:li:activity:6568218380594098176… articles are also in my profile:https://www.linkedin.com/pulse/cecs-cc-error-control-system-vasilei… I have also released the library on github:https://github.com/terablade2001/CECS I'd like to note that the library has been favored till now by 7 accounts in github (8 including me) which, for me, is also a positive feedback. Thanks for your time,V. Pothos

1 0

[GSOC19] Congrats to all students and mentors
by Damian Vicino 06 Sep '19

06 Sep '19

Hi, GSOC finished for 2019. We had 11 students this year and all of them survived the summer and contributed a lot of good stuff. Hopefully, most of it will be merged in the next few weeks. Thanks to all students and mentors, and to Boost community for supporting the program. Special thanks to David Bellot that worked as org admin and dealed with the logistics in addition to mentor. Cheers, Damian

2 1

[bimap] Maintaining library
by Edward Diener 04 Sep '19

04 Sep '19

Could someone please take a look at bimap in order to maintain the library. I have had a simple PR since last December, simply to remove executable permissions from some files, which has been ignored and no one appears to be maintaining the library.

1 0

boost::asio::deadline_timer and boost::asio::io_service
by JH 02 Sep '19

02 Sep '19

Hi, I use a single thread to run 3 classes using boost::asio::deadline_timer, the timers are managed by boost::asio::io_service. I deliberately use a single thread to avoid mutex, I believe those 3 timers are called exclusively by boost::asio::io_service in a single thread, there won't be race condition to share the objects among them, is it correct? Thank you. Kind regards, - jupiter

2 7

Re: [boost] A solution to return dynamic strings without heap allocation. Any interest?
by Bjorn Reese 01 Sep '19

01 Sep '19

On 8/29/19 3:24 PM, Roberto Hinz via Boost wrote: > auto result = csw.finish(); > if (result.truncated) { > // ... I suggest that you change the return type of finish() to contain the number of element written instead of the truncated boolean. This would make outbuf extensible to binary data as well where you cannot rely on a terminating zero to tell you how much data has been written. The return type could also have begin()/end() member functions, which makes it directly usable with STL algorithms. In that case it would also make sense to have data()/size().

2 3

Re: [boost] [Boost-users] License Issue with boost_intrusive
by Michael Caisse 27 Aug '19

27 Aug '19

Copying to dev ML. On 8/22/19 12:05, Gerald Wiltse via Boost-users wrote: > During an annual third-party audit of our source code, boost intrusive > was flagged as containing unlicensed code. Specifically, there are > several pieces of code in this file which are explicitly attributed to > external parties on external websites, which still exist and show no > license. > > https://github.com/boostorg/intrusive/blob/develop/include/boost/intrusive/… > > https://github.com/boostorg/intrusive/blob/develop/include/boost/intrusive/… > > > Original sources: > http://stackoverflow.com/questions/11376288/fast-computing-of-log2-for-64-b… > http://www.flipcode.com/archives/Fast_log_Function.shtml > > I don't claim to be a license expert. I've read a lot over the years, > but this is the first time that I've actually been between an attorney > and a codebase having to figure out practical implications of a scenario > like this. > > I first want to make sure that Boost committee is aware of this situation. > > Second, I would like to know what the official conclusion would be from > the Boost Committee about the license implications in cases like these. > Maybe it has come up before and is well established. On the surface, the > implications seems ambiguous to me when: DEVELOPER_A takes unlicensed > code off the internet, prefixes it with a comment that says "Thanks to > DEVELOPER_B ", then prefixes the whole file with a file-level copyright > notice that says "COPYRIGHT DEVELOPER_A", and then says it's > distributed under BSL-1.0 license, and then the boost team > re-distributes the source code. > > Internally at my company, there was little discussion about it. There > is no room for ambiguity, so the directive from management was to delete > the file from our SCM system completely and ensure it never is included > in our products. VERY fortunately, deleting it doesn't seem to have > broken our builds. In future cases like this, that's really not what we > want to be doing with your OSS libraries for obvious reasons. So, I'd > like to know if there's any chance this situation changes in a future > version of Boost (I.E., the code be removed/re-written with clean-room > approach, etc). > > Regards, > Jerry > > Gerald R. Wiltse > jerrywiltse(a)gmail.com <mailto:jerrywiltse@gmail.com> > > > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > https://lists.boost.org/mailman/listinfo.cgi/boost-users >

8 8

Set deadline_timer expired_at realtime clock 0 minute and repeat
by JH 27 Aug '19

27 Aug '19

Hi, How can I set deadline_timer expired at real clock absolute time at 0 minute, then repeat every minute? So it should expired at: 13:40:00, 13:41:00, 13:42:00 and so on? Thank you. Kind regards, - jupiter

2 7

Becoming the new maintainer of Boost.Functional/Factory (value_factory and factory)
by Glen Fernandes 26 Aug '19

26 Aug '19

Tobias (see forwarded e-mail below) has kindly agreed to allow me to become the maintainer of boost::factory and boost::value_factory (in Boost.Functional). I'll be revising the implementation of both for the next Boost (1.72) release, to: * Support r-value arguments * Use variadic templates to support arbitrary arguments * Support allocators that are final * Support allocators that use non-raw (fancy) pointers * Support BOOST_NO_EXCEPTIONS environments * Improve compilation times (drop Boost.Preprocessor usage) I'll add myself to the appropriate repository teams and update the library information accordingly. Glen ---------- Forwarded message --------- From: T.Schwinger <tschwinger(a)isonews2.com> Date: Mon, Aug 26, 2019 at 5:38 AM Subject: Re: Maintaining Boost.Functional value_factory and factory To: Glen Fernandes <glen.fernandes(a)gmail.com> Hi Glen, On 25.08.19 19:46, Glen Fernandes wrote: > I'd like to assume maintenance of factory/value_factory in > Boost.Functional. Among other things, update them to support r-value > references (when the compiler supports it), as well as simplify the > implementation for when the compiler supports variadic templates. > Along with other work going forward. [...] > If you have no objections let me know. No objections - to the contrary: I'm grateful. Thank you for taking care of it! Best, Toby

1 0

Compliance with Boost copyright and license guidelines
by pbristow＠hetp.u-net.com 23 Aug '19

23 Aug '19

Prompted by some recent discussion of Boost license and copyright info by the Debian package team, I have recently been checking on the Boost.Multiprecision library and run the Boost inspect program https://www.boost.org/doc/libs/1_70_0/tools/inspect/ (originally written by Beman Dawes in 2003 and revised several times since). I’ve made some minor cosmetic changes to the program and the rather sparse documentation to make it easier to use by library authors and give a bit more info. It checks on compliance with https://www.boost.org/development/requirements.html. It’s use has been a little neglected recently but I conclude that we are not doing well enough in providing the proof of copyright and license that we promise. The results of my run of inspect on the boost/lib folder using develop branch are not pretty Problem counts: 1790 files missing Boost license info or having wrong reference text 1682 files missing copyright notice (but not I suspect quite as bad as they look – some items probably do not need copyright and license). Now that the 1.71 release is out bar a little shouting, I wonder if we should focus on improving compliance for the next release? I’d like to propose 1 A boost/tools/inspect/develop branch to refine the inspect program a little and improve the documentation (I have done something on this already for my education and use). 2 Discussion of the bad results (zip attached) to try to find why there are so many reports and to decide what to do. 3 Encourage all authors to run inspect on their library locally and try to remedy the items missing. 4 I suspect that many libraries will have items missing but the authors are also missing. So someone from the community maintenance team will need to take over and make some decisions on what to do. Often just providing a copyright claim from the obvious author and Boost license will suffice? 5 Try to improve the compliance with other guidelines. For example. there are many libraries that are failing to prevent with min and max macros for what of a couple of brackets. Usually (std::numeric_limits<>::max)(). All these will trip up Windows users in a puzzling way. Please can we just fix these? Views? Paul PS My halo is shining brightly 😉 Boost.Multiprecision has a problem count of zero 😊 (and I’m working on Boost.Math) Boost Inspection Report Inspect version no 3.1.15 Run Date: 08:44:19 UTC, Saturday 17 August 2019 Distributed under the Boost Software License, Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) Copyright Boost 2019 boost-no-inspect Inspection from path "libs" including subfolders. Totals: 52355 files scanned 4351 directories scanned (including root) 3472 problems reported Problem counts: 1790 files missing Boost license info or having wrong reference text 1682 files missing copyright notice Worst Offenders: outcome 940 metaparse 556 polygon 228 python 194 beast 192 Summary: algorithm (4) array (2) asio (12) … Paul A. Bristow Prizet Farmhouse Kendal, Cumbria LA8 8AB UK

14 34

Re: [boost] crc.hpp:569 msvc warning C4800
by Kenneth Porter 22 Aug '19

22 Aug '19

This appears not to have made it into 1.71.0. I had to edit crc.hpp:569 to silence the warning. --On Saturday, April 13, 2019 1:35 PM -0700 Kenneth Porter via Boost <boost(a)lists.boost.org> wrote: > <https://github.com/boostorg/crc/pull/2> > > Visual Studio 2010-2019 issue this warning for crc.hpp line 569: > > warning C4800: "'int' : forcing value to bool 'true' or 'false' > (performance warning) > > bool const quotient = remainder & high_bit_mask; > > Replace with: > > bool const quotient = (remainder & high_bit_mask) != 0;

1 0

boost high precision timer and boost io_service
by JH 22 Aug '19

22 Aug '19

Hi, I am currently running boost::asio::deadline_timer to transmit data every minute, the requirement needs the interval accurate, if the first data sending at 10:00:05, the next needs be 10:01:05 and so on, but my data sending time shifting every 2 seconds I need to fix it. I am not sure if the boost high precision timer can fix it, it seems to me like a realtime requirement. My whole application is based on boost::asio::io_service in a single thread on Linux embedded system, can the boost high precision timer fix the problem or will the the boost multithreading fix the problem or there might be no chance to match the requirement simply because Linux is not a realtime OS? Appreciate your insight advice. Thank you. Kind regards, - jupiter

4 5

[release] Boost 1.71.0
by Michael Caisse 21 Aug '19

21 Aug '19

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

3 2

[release] Boost 1.71.0 Release Candidate 2 available
by Michael Caisse 20 Aug '19

20 Aug '19

The release candidates for the 1.71.0 release are now available at: <https://dl.bintray.com/boostorg/release/1.71.0/source/> The SHA256 checksums are as follows: 1b3949ffddf56129141032542523920034f2e69775fb9332a52ba37c548dbf35 boost_1_71_0_rc2.7z d73a8da01e8bf8c7eda40b4c84915071a8c8a0df4a6734537ddde4a8580524ee boost_1_71_0_rc2.tar.bz2 96b34f7468f26a141f6020efb813f1a2f3dfb9797ecf76a7d7cbd843cc95f5bd boost_1_71_0_rc2.tar.gz 85a94ac71c28e59cf97a96714e4c58a18550c227ac8b0388c260d6c717e47a69 boost_1_71_0_rc2.zip As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Boost Release Managers

5 6

Potential project: Resolving boost::chrono conflicts with std::chrono
by Howard Hinnant 20 Aug '19

20 Aug '19

Possible project for someone looking for a boost project to contribute to: boost::chrono was created soon after std::chrono was proposed and served people well for experimenting with this library prior to migrating to C++11. Fast forward 8 years: Now we have two competing chrono libraries: boost::chrono and std::chrono. And it is not rare for people to use non-chrono boost libraries, which in turn use boost::chrono, and for those same people to use std::chrono. Invariably what happens is they get horribly complicated compile-time errors which boil down to: boost::chrono does not interoperate with std::chrono. And these errors often come from deep within libraries which people are simply trying to use. The pitch: boost::chrono, and other boost::libs needs to defer to std::chrono for C++11 and later. This would make boost significantly easier to use. This is likely a multi-project effort, and I don’t even have a concrete strategy in mind. This is a problem in search of a solution, not vice-versa. And I often hear of enthusiastic people who want to jump in and lend a helping hand. I think this would be a terrific area to point such talent towards. Howard

13 27

Re: [boost] [multiprecision] Proposal for enhancing cpp_int multiplication
by kotika98 19 Aug '19

19 Aug '19

-------- Original message --------From: Ankur Dua via Boost <boost(a)lists.boost.org> Date: 17/08/2019 18:17 (GMT+08:00) To: boost(a)lists.boost.org Cc: Ankur Dua <ankurdua15(a)gmail.com> Subject: [boost] [multiprecision] Proposal for enhancing cpp_int multiplication We have benchmarked cpp_int vs mpz_int (GNU GMP backend) and we found thataround 10^6 bits, cpp_int is tremendously slow (almost 1200x times). Wehave also prepared a document containing the benchmarks [1] alongwith thedetails about the idea and the project.References,[1] Introductory document -https://docs.google.com/document/d/1cclKlbBWDVmY9zKSdn0ga2yTcCkyD9ZiUUdCZZkVyaI/edit?usp=sharing__________________________________________________________________________________ Nice idea for a project! In GMP, things are organized around thresholds for switching to the next algorithm. It is impossible to predict theoretically what that threshold will be or how it will evolve in the future with changes to computer architecture.1. However, for very large input, FFT dominates over Karatsuba and Toom. The threshold is around 4000 limbs which is roughly 250,000 bits. BTW, it is below your test limits.2. For most sizes in between 0 and 4000 limbs, Toom-8 dominates, not Karatsuba.3. Karatsuba and Toom are anyway both special cases of FFT.https://gmplib.org/manual/Multiplication-Algorithms.html#Multiplication…

1 0

I'm getting some neat results by changing graph testing over to using pre-compiled headers
by jrmarsha 18 Aug '19

18 Aug '19

Shout out to Rene Rivera for helping me get this stuff together. I'm getting some useful results out of changing to using pre-compiled headers. There isn't the speed-up I expected, but it has actually turned out useful for finding out incorrect header inclusion patterns and will certainly be making the code more reliable. This is something that we ought to consider trying more broadly in the project.

1 0

[multiprecision] Proposal for enhancing cpp_int multiplication
by Ankur Dua 18 Aug '19

18 Aug '19

Hi Boost community, We are team of two students (Senior Undergraduate) from IIT(ISM) Dhanbad — Madhur Chauhan & Ankur Dua. We want to bring your attention towards the the potential project that we wish to complete — Enhancing multplication of cpp_int by using Karatsuba as the multiplication algorithm. We have benchmarked cpp_int vs mpz_int (GNU GMP backend) and we found that around 10^6 bits, cpp_int is tremendously slow (almost 1200x times). We have also prepared a document containing the benchmarks [1] alongwith the details about the idea and the project. We are awaiting response from the community after which we will prepare a formal proposal containing the details of approach and possible implementations with documentation and test code changes. Thanks & Regards Madhur Chauhan & Ankur Dua madhur4127(a)gmail.com ankurdua15(a)gmail.com References, [1] Introductory document - https://docs.google.com/document/d/1cclKlbBWDVmY9zKSdn0ga2yTcCkyD9ZiUUdCZZk…

2 1

Interest in updated, standalone iterator_facade library?
by Zach Laine 18 Aug '19

18 Aug '19

I write a lot of iterators, and I'm getting sick of doing it by hand. I can't use Boost.Iterator's iterator_facade in library code, since it knows nothing about constexpr and noexcept. The design of Boost.Iterator's iterator_facade does not lend itself very well to being modified in a direction that is standardization-friendly (reasons why are outlined in the online docs). So, here is one take on this problem: GitHub: https://github.com/tzlaine/iterator_facade Online Docs: https://tzlaine.github.io/iterator_facade For those unfamiliar with the problem, iterators are very simple, at the highest level of abstraction. An iterator's implementation does not reflect this -- it is highly repetitive and easy to get subtly wrong. This library fixes that. The library is forward-looking, since I intend to write WG21 papers to standardize iterator_facade; there is good support for upcoming C++20 library features. In particular, the iterators created with iterator_facade model the C++20 iterator concepts, and therefore do not necessarily match the requirements of the C++17-and-earlier requirement tables. I have not found this to affect the usability of iterator-facade-based iterators with pre-C++20 code. Something to note: there was a recent-ish attempt to stanrdize iterator_facade, which is now abandoned, P0186 (http://wg21.link/P0186) This was very different from what I'm proposing for Boost. I talked to Eric Niebler about this, and he favors a return to the CRTP-based approach of my lib and the original Boost.Iterator iterator_facade library. Zach

9 20

Interest in STL interface templates for iterators, views, and containers? (Was: Interest in updated, standalone iterator_facade library?)
by Zach Laine 17 Aug '19

17 Aug '19

On Wed, Aug 14, 2019 at 10:44 AM Zach Laine <whatwasthataddress(a)gmail.com> wrote: > On Wed, Aug 14, 2019 at 4:44 AM Hans Dembinski <hans.dembinski(a)gmail.com> > wrote: > > [snip] > > >> > Since iterator_interface is a lot more like Boost.Iterator's >> iterator_adaptor than my previous iterator_facade was (and I'll look into >> that), it may be possible to make one template that does everything, but I >> will not include two separate templates. >> >> If you could merge the two that would be even better, but I am not sure >> you can. >> > > I can, and I did last night. You can see an example here (not that this > is not the master branch): > > > https://github.com/tzlaine/iterator_facade/blob/interface_alternative/examp… > > When I get MSVC fixed, I'll merge all this to master. > This is now done. The focus of the library is now a bit different. All the iterator bits are still there, but now iterator_facade is called iterator_interface, and has facilities for acting more like an iterator_facade and more like an iterator_adaptor. One of the new things is an implementation of C++20's view_interface. Give it a range or view, even one with only begin() and end(), and it gives you all the view-type API that can be supported from begin() and end(), based on the iterator types and categories. The other new thing is container_interface. It is analogous to view_interface, but instead of supporting definition of new view types, it supports the definition of new containers. It has support for all the operations in the sequence container and reversible container requirements in the standard. In the example in the docs, I was able to write a static_vector, for which container_interface provided 38(!) of the member functions. Finally, the library's name has changed to reflect all this. You can now get the code here: https://github.com/tzlaine/stl_interfaces and see the online docs here: https://tzlaine.github.io/stl_interfaces/doc/html/index.html Zach

1 0

Beast/Context build failures
by Vinnie Falco 15 Aug '19

15 Aug '19

I'm seeing new build failures related to Boost.Context, could this be the recent changes there? <https://travis-ci.org/boostorg/beast/jobs/571029999> Thanks

3 2

Boost.Predef still broken in 1.71 RC 1
by Niall Douglas 13 Aug '19

13 Aug '19

As reported earlier, Boost.Build's predefined macro testing support is still misdetecting in RC 1: Using Boost 1.71 RC 1 with VS2019: b2 libs/outcome/test Performing configuration checks - default address-model : 32-bit - default architecture : x86 - !BOOST_COMP_GNUC : no - BOOST_COMP_GNUC >= 6.0 : no - !BOOST_COMP_CLANG : no - BOOST_COMP_CLANG >= 4.0 : no - Boost.Config Feature Check: cxx14_variable_templates : yes - Boost.Config Feature Check: cxx14_constexpr : yes - !BOOST_COMP_GNUC : no - BOOST_COMP_GNUC >= 6.0 : no - !BOOST_COMP_CLANG : no - BOOST_COMP_CLANG >= 4.0 : no - Boost.Config Feature Check: cxx14_variable_templates : yes - Boost.Config Feature Check: cxx14_constexpr : yes ...found 1 target... Using Boost 1.71 RC 1 with GCC 7.3 on Linux: g++ --version g++ (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0 Copyright (C) 2017 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ./b2 libs/outcome/test Performing configuration checks - !BOOST_COMP_GNUC : no - BOOST_COMP_GNUC >= 6.0 : no - !BOOST_COMP_CLANG : no - BOOST_COMP_CLANG >= 4.0 : no - default address-model : 64-bit - default architecture : x86 - Boost.Config Feature Check: cxx14_variable_templates : yes - Boost.Config Feature Check: cxx14_constexpr : yes - !BOOST_COMP_GNUC : no - BOOST_COMP_GNUC >= 6.0 : no - !BOOST_COMP_CLANG : no - BOOST_COMP_CLANG >= 4.0 : no - Boost.Config Feature Check: cxx14_variable_templates : yes - Boost.Config Feature Check: cxx14_constexpr : yes ...found 1 target...

2 2

Re: [boost] Potential project: Resolving boost::chrono conflicts with std::chrono
by Glen Fernandes 12 Aug '19

12 Aug '19

Howard wrote: > There is truth to this rationale, but I also wanted to point out that it is not absolute. > [snip] > Not providing a boost implementation does not preclude enhancing a std::lib. > But it can certainly help in changing existing signatures, Indeed. Of course, someone who wants to prototype some breaking change to a library like chrono or smart_ptr can do it without Boost. For example, we could have reimplemented ALL of shared_ptr in github/JohnDoe/smart_ptr to prototype the extensions added in C++17 and C++20. But here were some advantages of not doing so, and using Boost instead: - NOT reimplementing ALL of shared_ptr - Access to a bigger user base than github/JohnDoe/smart_ptr would have e.g. * Boost being white-listed as approved open source in many organizations * New versions of Boost included in many Linux distribution software repositories * etc. So it was an easy choice to go through Boost because boost::shared_ptr wasn't just an alias for std::shared_ptr, and had a quality, well tested, implementation. Still, even with Smart_Ptr, you have the option to convince the maintainer of Smart_Ptr to make boost::shared_ptr just an alias for [C++17] std::shared_ptr, and make boost::allocate_shared just defer to [C++20] std::allocate_shared. It would make users unhappy. There are already users of boost::local_shared_ptr which depends on the implementation of boost::shared_ptr, that would continue using Boost even after C++20 features are implemented everywhere. Glen

1 0

Re: [boost] Potential project: Resolving boost::chrono conflicts with std::chrono
by Glen Fernandes 12 Aug '19

12 Aug '19

There is value in Boost.Chrono providing a chrono implementation (i.e. not just aliasing std::chrono), to provide a library where future enhancements to chrono could eventually make it into C++23, or beyond. i.e. Similar to how we enhanced std::shared_ptr, std::make_shared, std::allocate_shared past the C++11 versions, and these enhancements made it into C++17 and C++20. Other Boost libraries can switch today to use std::chrono instead of boost::chrono (conditionally or unconditionally) if they want. As always: - It is, up to the maintainer of Boost.Chrono whether he wants to use std::chrono internally, and make boost::chrono compatible with std::chrono. - It is up to the maintainers of other Boost libraries whether they want to use std::chrono instead of boost::chrono Both of these can be achieved independently, purely by convincing the respective Boost maintainers. Maybe they can drop C++11 support and only support std::chrono. Maybe they might want to use boost::chrono in C++03 mode and std::chrono in C++11 mode. The discussion on the Boost mailing list (each time it gets repeated, for Boost.X library for which there is a C++ standard library equivalent) while still interesting, probably still won't achieve anything. i.e. No amount of discussion here is going to result in any action to command any maintainer to do something. Glen

2 1

[release] Boost 1.71.0 Release Candidate 1
by Michael Caisse 11 Aug '19

11 Aug '19

The first release candidates for the 1.71.0 release are now available at: <https://dl.bintray.com/boostorg/release/1.71.0.rc1/source/> The SHA256 checksums are as follows: 7fadf835372325d7a287b1c45310c4f96811eb1e4809933a5a400d529df38d0e boost_1_71_0_rc1.7z c857a86fb1223c7a256414151e2d1dcd4691b56197aa1329e087e92502191434 boost_1_71_0_rc1.tar.bz2 07c07cad079fed3f0175cbd7097740a333c2cdc6c899ac433dea87d1224d726d boost_1_71_0_rc1.tar.gz bc1674ba3e11635fc2effbddc2ed69aecaced3901f81a6a2aae7b77f34e4cf76 boost_1_71_0_rc1.zip As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.

5 7

[asio][coroutine] Intentional synchronization of a single coroutine
by Jared McIntyre 10 Aug '19

10 Aug '19

Within a large asynchronous project, I have a coroutine that needs to synchronize with other calls to that coroutine. This is a very simplified (and somewhat silly) example: #include <iostream> #include <cstdlib> #include <chrono> #include <boost/asio.hpp> #include <boost/asio/spawn.hpp> using namespace std; using namespace std::chrono; using namespace std::placeholders; using namespace boost::asio; using namespace std::chrono_literals; io_service ioservice; void bottleneck(seconds duration, yield_context yield) { steady_timer delay_timer(ioservice); delay_timer.expires_after(duration); delay_timer.async_wait(yield); std::cout << duration.count() << " "; } int main() { spawn(ioservice, std::bind(&bottleneck, 3s, _1)); spawn(ioservice, std::bind(&bottleneck, 2s, _1)); spawn(ioservice, std::bind(&bottleneck, 1s, _1)); spawn(ioservice, std::bind(&bottleneck, 0s, _1)); ioservice.run(); } The output is, of course, 0 1 2 3 because the timer effectively acts to re-order the calls. What I need is a way for each call to bottleneck() to fully complete before the next one starts, and each call occurs in the order they were called. This would make the output 3 2 1 0. I also want to allow other asynchronous routines on the io_service to run when the coroutine is yielding (so no cheating and turning the delay timer into a sleep). I've tried to think through something like the following. But I have no idea how to make it work. yield_context_queue bottleneck_queue; void bottleneck(seconds duration, yield_context yield) { bool yield_time = !bottleneck_queue.empty() bottleneck_queue.push_back(yield); if( yield_time ) { yield_back; } steady_timer delay_timer(ioservice); delay_timer.expires_after(duration); delay_timer.async_wait(yield); std::cout << duration.count() << " "; bottleneck_queue.pop(); if( false == bottleneck_queue.empty() ) { ioservice.post(bottleneck_queue.peak()); } }

3 2

Re: [boost] [asio][coroutine] Intentional synchronization of a single coroutine
by Bjorn Reese 10 Aug '19

10 Aug '19

On 8/9/19 9:12 PM, Jared McIntyre via Boost wrote: > The output is, of course, 0 1 2 3 because the timer effectively acts to > re-order the calls. What I need is a way for each call to bottleneck() to > fully complete before the next one starts, and each call occurs in the > order they were called. This would make the output 3 2 1 0. I also want to > allow other asynchronous routines on the io_service to run when the > coroutine is yielding (so no cheating and turning the delay timer into a > sleep). This sounds like a job for Boost.Fiber and its Boost.Asio integration: https://www.boost.org/libs/fiber/doc/html/fiber/callbacks/then_there_s____b…

2 1

[release] master branch closes soon - check build status
by Michael Caisse 09 Aug '19

09 Aug '19

The master branch will be closing soon (in about 30-hours). Please check the build status of your library. <https://www.boost.org/development/tests/master/developer/summary.html> - Your Friendly Boost Release Team

4 6

[release] 1.71.0 closed for Beta
by Michael Caisse 09 Aug '19

09 Aug '19

The master branch is now closed for all changes except by permission for the Beta release. Also, remember to add your libraries' changes to the release notes at: <https://github.com/boostorg/website/blob/master/feed/history/boost_1_71_0.q…> Thanks, -- The Boost Release Team

1 0

Re: [boost] Potential project: Resolving boost::chrono conflicts with std::chrono
by Bjorn Reese 09 Aug '19

09 Aug '19

On 8/9/19 3:01 AM, Howard Hinnant via Boost wrote: > The pitch: boost::chrono, and other boost::libs needs to defer to std::chrono for C++11 and later. This would make This should be done with great care. Boost.Asio does exactly this for its timer classes -- use boost::chrono if compiled pre-C++11 and otherwise use std::chrono. As implemented, this is a pain from the users perspective, because the user has to pass a type-strong expiration parameter which can be either, say, std::chrono::seconds or boost::chrono::seconds. This means, that your code that works perfectly suddenly yields compilation errors when your users change the compiler flags. boost::asio::steady_timer timer; timer.expires_from_now(boost::chrono::seconds(5)); // Fails post C++03 The Boost.Asio way is to import all chrono symbols into its own namespace: boost::asio::steady_timer timer; timer.expires_from_now(boost::asio::chrono::seconds(5)); // Okay Another solution is to use the timer template classes, e.g. basic_waitable_timer instead of steady_timer, so the user can work around the problem by selecting whether to use std::chrono or boost::chrono: boost::asio::basic_waitable_timer<boost::chrono::steady_clock> timer; timer.expires_from_now(boost::chrono::seconds(5)); // Okay PS: I am not arguing for or against the project, nor am I recommending any particular solution. I am just sharing some experience.

2 1

Result of out_ptr review.
by Zach Laine 07 Aug '19

07 Aug '19

I've compiled the results of the reviews of out_ptr during its recent review. Unfortunately, out_ptr is NOT ACCEPTED, though many of the reviewers indicated interest in seeing it come back in some future form. I counted these formal reviews: Andrey Semashev: reject Louis Dionne: accept David Sankel: reject Phil Endecott: reject Glen Fernandes: reject Gavin Lambert: reject Thanks to all of the above reviewers, and to all those who contributed to the ongoing discussions surrounding out_ptr, even if they did not have time for a full review. Points against out_ptr raised during the review: - Many reviewers indicated their puzzlement that this library was proposed at all, since they had never seen enough calls to C APIs in their own code to motivate the need for out_ptr. - Some reviewers who did find the motivating cases of the library compelling, still said that they would prefer to write wrappers instead of using something like out_ptr. - Multiple reviewers want the library to provide error-reporting help (it currently does not). In particular, for c_func(out_ptr(p)), there was a concern about whether p is assigned a value, when c_func() returns a failure-status. - There was concern from several reviewers about the fact that out_ptr's types' dtors may throw, though this is only limited to the use of out_ptr with shared_ptr and similar smart pointers. In particular, non-unique_ptr uses will never throw in out_ptr's types' dtors, unless the user provides a throwing deleter. - Multiple reviewers disagreed with the use of template specialization as a customization mechanism. - There was widespread concern about the use of potentially UB-invoking tricks to get max performance out of the implementation. - Many reviewers wanted a more typical Boost tutorial introduction in the documentation. Now please permit me a digression. The library attempts to take a call that looks like this (simplest call possible): // CASE 0 foo * new_foo; TODO if (!create_foo(&new_foo)) { // etc. ... } And turn it into something as close as possible to this: // CASE 1 std::unique_ptr<foo> new_foo; if (!create_foo(new_foo)) { // etc. ... } out_ptr does a great job of this lexically: // CASE 2 std::unique_ptr<foo> new_foo; if (!create_foo(out_ptr(new_foo))) { // etc. ... } If you have not written thousands of lines of code that look like case 0, stop for a second and consider what it would be like to drop those thousands of raw pointers into your code, and how much you would like to replace them all with unique_ptrs. Now consider what it would take you to write all the wrapping functions necessary to make those thousands of calls look like case 1. You may make tooling to generate the wrappers, and that's time consuming. Writing it by hand is even more so. out_ptr also has the nice property that using it as I have above with unique_ptr does not change the meaning of the code, except to ensure that new_foo is guaranteed to be treated in a RAII manner. Thus we get increased exception safety, memory leak mitigation, etc. -- y'know, all that RAII stuff. If out_ptr is implemented well, case 2 should produce nearly identical object code to case 0, except that case 2 handles calling new_foo's dtor at the right time. Note that because of this, you have the same relationship to the C API in all three cases. That is, you need to check for the success value returned from create_foo(), and you need to know what create_foo()'s contract is in the face of errors -- did it write to new_foo or not? out_ptr is how you get from raw pointers to RAII ones, not how you solve all programming problems related to calling functions. Hopefully that motivates the use case for out_ptr, even if you don't need it in your own code. Hopefully that also allays concerns that out_ptr is not doing enough -- doing more is outside the library's scope. Now, on to exceptions in out_ptr's types' dtors. I heard a lot of discussion about this during the review. To me, concerns about what happens when an out_ptr or an inout_ptr throws in its dtor misses the point entirely, because it is concerned with fixing corner cases we should not even care to support. Instead of worrying about the semantics of exceptions in those kinds of situations, we should instead be asking why we want to support user code like this: ... } catch { create_foo(in_out_ptr(my_shared_ptr_to_a_foo)); ... } In other words, we don't really care about the dtor exceptions, unless: - there is an active exception already, and - we are also calling a C API to create a new object (a possible, but certainly atypical thing to do when handling an exception), and - we're catching this new object in a shared_ptr-like smart pointer that might throw on construction. Who writes code like that? Few people, perhaps none. It's not impossible to see code like that, but until there are well-motivated cases for this, maybe leave it for a later version of the library. In other words, the question should have been "Why support anything other than nothrow-constructible RAII types like unque_ptr?" Note that I find this argument compelling for the WG21-facing version of this work too. To summarize: I think the first four bullet points listed at the beginning of this post are, or could easily be made to be, irrelevant. So, that leaves some issues still outstanding: - figure out how to provide customization points (I'm actually fine with the current approach...), - eliminate the UB-dangerous code, or make it opt-in, - rework the tutorial portion of the docs, and - many assorted doc cleanups. That does not seem like an unreasonable amount of stuff to resolve in post-review acceptance readiness. I bring all this up because I do in fact hope that JeanHeyd brings this back for a future review, and I hope that my arguments here will convince some of you that this library is a useful thing to have around. I waited until now to say any of these things in an attempt to remain impartial during the review; I've been bothered by seeing previous review managers clearly represent a pro-acceptance position from the start. Thanks to JeanHeyd for his submission. A no-vote from this group is a tough thing, and I hope that the feedback he has received takes some of the sting out. Zach

6 5

[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

Making copyright holders easier to parse
by Giovanni Mascellani 07 Aug '19

07 Aug '19

Dear Boost developers, I am one of the Debian developers maintaining the Boost package in Debian. As part of packaging policy, we want the copyright status of each file in Debian packages to be documented, which includes at least the name of the copyright holders and the license of that particular file. As you can believe, this is rather complicated for Boost, since there are a lot of files with many copyright holders. I started to use the tool bcp, which among other things is able to collect such copyright information. My clone is available here[1]. However, bcp often is confused by the inconsistent style of how copyright holders are listed in different files, so it required a lot a manual fixing. For example, sometimes copyright years are written before the name, sometimes after, sometimes they're absent; names are sometimes separated by commas, sometimes by newlines, maybe even sometimes by nothing. Sometimes there are spelling mistakes or casing inconsistencies between names, or inconsistent institutions' names. Bcp has some complicated regular expression to overcame all these differences, but the result is brittle at its best. [1] https://salsa.debian.org/gio/boost-copyright Since I am doing this manual work anyway, I might as well update the Boost files so that their copyright headers are more consistent and easy to parse, and then I could submit you patches for having them fixed in the Boost official repositories. My question is: are you interested in this kind of patches? Of course I would still go through the ordinary patch submission procedure. I am just asking if this kind of patches would be well received or not. To better illustrate what I mean, let me consider a few examples (the chosen files are completely random); file libs/log/include/boost/log/exceptions.hpp currently has: > /* > * Copyright Andrey Semashev 2007 - 2015. > * Distributed under the Boost Software License, Version 1.0. > * (See accompanying file LICENSE_1_0.txt or copy at > * http://www.boost.org/LICENSE_1_0.txt) > */ I might change this to: > /* > * Copyright: 2007-2015 Andrey Semashev > * License: Boost Software License, Version 1.0 > * (See accompanying file LICENSE_1_0.txt or copy at > * http://www.boost.org/LICENSE_1_0.txt) > */ File libs/atomic/include/boost/atomic/fences.hpp has: > /* > * Distributed under the Boost Software License, Version 1.0. > * (See accompanying file LICENSE_1_0.txt or copy at > * http://www.boost.org/LICENSE_1_0.txt) > * > * Copyright (c) 2011 Helge Bahmann > * Copyright (c) 2013 Tim Blechmann > * Copyright (c) 2014 Andrey Semashev > */ I might change this to: > /* > * Copyright: 2011 Helge Bahmann > * Copyright: 2013 Tim Blechmann > * Copyright: 2014 Andrey Semashev > * License: Boost Software License, Version 1.0 > * (See accompanying file LICENSE_1_0.txt or copy at > * http://www.boost.org/LICENSE_1_0.txt) > */ I hope these examples illustrate my intention. I think that having more easily parsable copyright holders could be useful for Debian, for Boost and for Boost adopters which should properly care about the licensing of the libraries they use. Thank you, Giovanni. -- Giovanni Mascellani <g.mascellani(a)gmail.com> Postdoc researcher - Université Libre de Bruxelles

14 23

Expansion of Boost.Algorithm
by ATHARVA VEER 06 Aug '19

06 Aug '19

Greetings to all! I am planning to expand Boost.Algorithm by including more of general purpose algorithms to it. But since I don't know the future roadmap of the module, I cannot suggest changes right now. Also I have couple of algorithms in my mind that I think would be great if they are part of Boost but I don't know if Boost.Algorithm is the right place to include them. So I was wondering if anyone is willing to mentor me (as in review my work and suggest changes before merging) and we could discuss what we could include in Boost.Algorithm or appropriate module to include them. Brief about myself:- I am junior year college student and I have some experience working in open-source. I haven't contributed to Boost before but have used Boost libraries in day to day life. Thank you!!

1 0

Boost 1.71.0 Beta 1 and Quantlib 1.15
by Cg K 06 Aug '19

06 Aug '19

Gentlemen, Please read this message from Quantlib Dev board <https://sourceforge.net/p/quantlib/mailman/message/36730686/> In short, I was not able to compile Quantlib 1.15 with Boost 1_71_0_b1_rc1 I was able to compile it with 1.70 with some creativity. See here. <https://sourceforge.net/p/quantlib/mailman/message/36732240/> I have a complete list of the errors and messages. It is some 36 pages long and thought it best not to attach. If anyone wants it I will gladly send it to them privately. kaucher(a)gmail.com

4 5

[quickbook] build errors on master
by Raffi Enficiaud 05 Aug '19

05 Aug '19

Hi, I just merged develop to master and I have quickbook errors on my CI (see errors below). The exact same code compiled at 27. July 2019 at 13:47:19 CEST. Does anyone know something about this? Thanks, Raffi 05-Aug-2019 21:44:37 /Users/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB-DOX/library/tools/quickbook/src/include_paths.cpp:160:18: error: no member named 'directory_iterator' in namespace 'boost::filesystem'; did you mean 'directory_entry'? 05-Aug-2019 21:44:37 for (fs::directory_iterator dir_i(base_dir), dir_e; dir_i != dir_e; 05-Aug-2019 21:44:37 ~~~~^ 05-Aug-2019 21:44:37 ../../../boost/filesystem/path_traits.hpp:48:9: note: 'directory_entry' declared here 05-Aug-2019 21:44:37 class directory_entry; 05-Aug-2019 21:44:37 ^ 05-Aug-2019 21:44:37 /Users/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB-DOX/library/tools/quickbook/src/include_paths.cpp:160:61: error: use of undeclared identifier 'dir_i' 05-Aug-2019 21:44:37 for (fs::directory_iterator dir_i(base_dir), dir_e; dir_i != dir_e; 05-Aug-2019 21:44:37 ^ 05-Aug-2019 21:44:37 /Users/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB-DOX/library/tools/quickbook/src/include_paths.cpp:160:70: error: use of undeclared identifier 'dir_e' 05-Aug-2019 21:44:37 for (fs::directory_iterator dir_i(base_dir), dir_e; dir_i != dir_e; 05-Aug-2019 21:44:37 ^ 05-Aug-2019 21:44:37 /Users/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB-DOX/library/tools/quickbook/src/include_paths.cpp:161:16: error: use of undeclared identifier 'dir_i' 05-Aug-2019 21:44:37 ++dir_i) { 05-Aug-2019 21:44:37 ^ 05-Aug-2019 21:44:37 /Users/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB-DOX/library/tools/quickbook/src/include_paths.cpp:162:26: error: use of undeclared identifier 'dir_i' 05-Aug-2019 21:44:37 fs::path f = dir_i->path().filename(); 05-Aug-2019 21:44:37 ^ 05-Aug-2019 21:44:37 /Users/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB-DOX/library/tools/quickbook/src/include_paths.cpp:170:41: error: use of undeclared identifier 'dir_i' 05-Aug-2019 21:44:37 if (fs::is_regular_file(dir_i->status())) { 05-Aug-2019 21:44:37 ^ 05-Aug-2019 21:44:37 /Users/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB-DOX/library/tools/quickbook/src/include_paths.cpp:178:42: error: use of undeclared identifier 'dir_i' 05-Aug-2019 21:44:37 if (!fs::is_regular_file(dir_i->status())) { 05-Aug-2019 21:44:37 ^ 05-Aug-2019 21:44:37 7 errors generated.

2 1

[release] 1.71.0 post-beta merges
by Michael Caisse 05 Aug '19

05 Aug '19

The master branch is is now open for post-beta merges, but only as described in the Post-Beta Merge Policy. See <https://github.com/boostorg/boost/wiki/Releases%3A-Beta-Merge-Policy> Thanks, -- The Boost Release Team

7 17

Expansion of Boost.Algorithm
by ATHARVA VEER 04 Aug '19

04 Aug '19

Greetings to all! I am planning to expand Boost.Algorithm by including more of general purpose algorithms to it. But since I don't know the future roadmap of the module, I cannot suggest changes right now. Also I have couple of algorithms in my mind that I think would be great if they are part of Boost but I don't know if Boost.Algorithm is the right place to include them. So *I was wondering if anyone is willing to mentor me (as in review my work and suggest changes before merging) and we could discuss what we could include in Boost.Algorithm.* Brief about myself:- I am junior year college student and I have some experience working in open-source. I haven't contributed to Boost before but have used Boost libraries in day to day life.

1 0

Boost.Accumulators regression in Boost 1.71 beta 1 on VC++17/19
by Luigi Ballabio 04 Aug '19

04 Aug '19

Hello, the attached minimal file fails to compile on VC++17/19 when using Boost 1.71.0b1. It compiles successfully with Boost 1.70.0. I also attach the compiler errors. Cheers, Luigi

1 1

ASIO socket wired observation
by JH 03 Aug '19

03 Aug '19

Hi, I have been using asio tcp socket on desktop Ubuntu for years, but I have never seriously run interface connections in a LTE embedded system, here is what I have observed wired thing: - Client initialized TCP socket connection to remote server, the connection was established. - Client sent data to server via Internet every one minute, all good. - Somehow, the LTE connection dropped, there was no any network connection available, but the client keep sent messages, there was no error about the network connection, the message obvious could not go Internet, it accumulated in the RAM, the original each message size was 79 bytes, the size was accumulated became 52790 bytes, it kept going for ever until I terminate the client program. ....... Send message size: 52790 Send message size: 52869 Send message size: 52948 ..... Is it normal behavior of ASIO socket or what I did wrong here? Appreciate your insight tips to fix this problem to trig client socket error not keeping sending message going no way. Thank you. Kind regards, - jupiter

2 1

How safer to use boos::shared_from_this() from derived class inherited from based class?
by JH 02 Aug '19

02 Aug '19

Hi, I have a derived base class: class Base : boost::enable_shared_from_this<Base> { public: Base(); virtual ~Base(); virtual boost::shared_ptr<Base> SharedFromThis(void) {return shared_from_this();} private: } class Derived : public Base { public: Derived(); ~Derived(); // boost::shared_ptr<Derived> SharedFromThis(void) {return boost::static_pointer_cast<Derived>(shared_from_this());} private: }; Applications are sharing the derived class, it can either use shared_ptr<Derived> or shared_ptr<Base> by calling the SharedFromThis(), three options: (1) Don't define derived class own SharedFromThis(), always call Base SharedFromThis() to pass shared_ptr<Base> as Derived shared_ptr, the reference count will be shared_ptr<Base>. (2) Define derived class its own SharedFromThis() and pass shared_ptr<Derived> to applications: boost::shared_ptr<Derived> SharedFromThis(void) {return boost::static_pointer_cast<Derived>(shared_from_this());} That one cannot be virtual as conflicted to Base SharedFromThis(), the reference count will always be boost::shared_ptr<Derived> (3) Mixed both boost::shared_ptr<Derived> and boost::shared_ptr<Base> in applications, that could be a bad option to cause segmentation as one shared_ptr could be ended before another shared_ptr. Which option will be safer? Thank you. Kind regards, - jupiter

2 2

Norton blocking Appveyor?
by John Maddock 01 Aug '19

01 Aug '19

Hi all, I see that my browser is just started blocking ci.appveyor.com which is a bit of a problem for CI to say the least. Is anyone else seeing this? Any ideas whether it's justified or spurious? Thanks, John. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

3 2

Final Call for Submissions: International Conference on Information Society (i-Society 2019)
by International Conference on Information Society 29 Jul '19

29 Jul '19

If you are not able to see this mail, click http://r.confinfosoc.org/mk/mr/dNqT-1si6HE5qHDv5cV6nrZEGnVvH63myFIAZaMHhWb9… Final Call for Submissions: International Conference on Information Society (i-Society 2019) The i-Society is a global knowledge-enriched collaborative effort that has its roots from both academia and industry. The conference covers a wide spectrum of topics that relate to information society, which includes technical and non-technical research areas. Submission Instructions: * You can submit your extended abstract or paper online at [ http://www.i-society.eu/paper-submission/ ]( http://r.confinfosoc.org/mk/cl/f/cKABES_5mIGAo8Mgp-cuui5DCd9DYYIrOsBvLgtLLN… )or email it to papers(a)i-society.eu * You can submit your poster via email at posters(a)i-society.eu * You can submit your workshop or tutorial proposal at workshop(a)i-society.eu or tutorial(a)i-society.eu * You can submit your speaker's proposal at speakers-2019(a)i-society.eu [ Submit ]( http://r.confinfosoc.org/mk/cl/f/FhV5CG1-0Pk8UtOQVyS5RSUsGqCAVXq-AH1LIwQW9t… ) This email was sent to boost(a)lists.boost.org You received this email because you are registered with Infonomics Society [ Unsubscribe here ]( http://r.confinfosoc.org/mk/un/07f-n0ocPpExwtzrl_PeKAeTG4ctupFicTSTp-RuT97r… ) [ ]( http://r.confinfosoc.org/mk/cl/f/j-a-1n1z1XvvyX_L5iaFp6R3gGFhBceWdCdqP1QnZF… ) © 2019 Infonomics Society

2 1

MSVC 2019
by Cg K 27 Jul '19

27 Jul '19

I recently installed Visual Studio 2019 and then Boost and Quantlib. I tried to compile Quantlb with the precompiled 1.70 boost. I go the error message: LINK : fatal error LNK1104: cannot open file 'libboost_unit_test_framework-vc142-mt-gd-x64-1_70.lib' It appears that compatibility with Visual Studio/MSVC 2019 has not been worked out in 1.70 given its release date was so close to the release date of Visual Studio 2019. I also noted the the beta for 1.71 was closed. Wondering if the beta fixes this or is there a workaround or is this a user error?

7 9

RSS1/RSS2/ATOM + P2P
by Ggh 27 Jul '19

27 Jul '19

Dear All, I invite you all to a debate/brainstorming on implementing an RSS library for boost, as well as an RSS+p2p protocol on the application layer on the TCP/IP stack. I do not claim that RSS should have an implementation in boost, however I think it might be a good idea. Lots of activity on http/application layer of the web and perhaps we/boost developers should consider an RSS extention to boost of RSS/Atom, with P2P capabilities. As always, comments and critisism is velcome. Thank you, Cheers Greg Tell me, and I forget. Ask me, and I discover...

1 0

proposals
by VALERIU SMERICA 27 Jul '19

27 Jul '19

Hello. Is it possible to propose some data structures to be part of Boost that use code under the Apache 2.0 license? Are there any legal issues with this? I heard Apache 2.0 license was pretty permissive. Thanks.

2 1

[release] Boost 1.71.0 Beta 1
by Michael Caisse 26 Jul '19

26 Jul '19

Boost release 1.71.0 beta 1 is now available at: <https://dl.bintray.com/boostorg/beta/1.71.0.beta1.rc1/source/> The SHA256 checksums are as follows: 451adc4f199c73e995e541f38c4dbd51faf4ce0db15537136ffd5213a1be5e55 boost_1_71_0_b1_rc1.7z a93d7066fc1514995aec0e726532a219447dd39b0ffa7cb97ca5736f16b0488b boost_1_71_0_b1_rc1.tar.bz2 34743b80466463e0c1b7fc71b677f326bdc242fe0b87a9c1599b6f7ea6e5c0cb boost_1_71_0_b1_rc1.tar.gz 5cd448bddc8394469391306e0ccada0a8f88c5c6cf8ec775ddf8e56adef8bbc2 boost_1_71_0_b1_rc1.zip For details of what's in the release, see <http://www.boost.org/users/history/version_1_71_0.html>. Note: Having some trouble getting the web page updated... check back with it soon. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

9 15

Boost proposals
by VALERIU SMERICA 26 Jul '19

26 Jul '19

Hello. Is it possible to propose some data structures to be part of Boost that use code under the Apache 2.0 license? Are there any legal issues with this? I heard Apache 2.0 license was pretty permissive. Thanks.

1 0

boost::serialization optional does not use boost::serialization::access
by Janek Kozicki 25 Jul '19

25 Jul '19

Hi, this simple program will not compile. The only way to make it work is to make a public default constructor. This defeats the purpose of boost::serialization::access. I tried to fix <boost/serialization/optional.hpp> but I couldn't get it to correctly call the access::construct(); Please help. // g++ -o serialize_optional /tmp/serialize_optional.cpp -lboost_serialization #include <fstream> #include <iostream> #include <boost/serialization/nvp.hpp> #include <boost/serialization/serialization.hpp> #include <boost/archive/xml_iarchive.hpp> #include <boost/archive/xml_oarchive.hpp> #include <boost/serialization/access.hpp> #include <boost/archive/text_oarchive.hpp> #include <boost/archive/text_iarchive.hpp> #include <boost/serialization/optional.hpp> #include <boost/optional.hpp> class Foo { public: Foo(int k) : i(k) {} friend std::ostream& operator<<(std::ostream& os, Foo const& foo) { return os << "Foo { " << foo.i << " }"; } private: Foo() : i(-1) {}; friend class boost::serialization::access; template<class Archive> void serialize(Archive & ar, const unsigned int){ #define N(a) BOOST_SERIALIZATION_NVP(a) ar & N(i); #undef N }; int i; }; int main() { using Data = boost::optional<Foo>; std::cout << "Boost version: " << BOOST_VERSION << "\n"; { auto f = Data(133); std::ofstream os("test.xml"); boost::archive::xml_oarchive oa(os); oa << boost::serialization::make_nvp("f", f); } { Data g; std::ifstream is("test.xml"); boost::archive::xml_iarchive ia(is); ia >> boost::serialization::make_nvp("f", g); std::cout << g.get() << "\n"; } } best regards Janek Kozicki

2 4

[gil] Missing doc/html/ files from Boost 1.70
by Mateusz Loskot 24 Jul '19

24 Jul '19

Hi, I'm following up this old report of mine [1] about missing GIL docs. Apparently, GIL documentation was not generated during the release process, so no files were copied wherever they should be. The documentation is missing from: - boost_1_70_0 source archives - https://www.boost.org/doc/libs/1_70_0/libs/gil/ Is it possible to fix the website at least, redirect it to valid URL? Can I fix it myself? How? [1] https://lists.boost.org/Archives/boost/2019/04/245985.php Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 1

[locale] Loss of precision (C4244) warnings in MSVC 64-bit build
by Kenneth Porter 24 Jul '19

24 Jul '19

Building with MSVC compilers for 64-bit results in several C4244 warnings in api.hpp, due to passing the difference of two pointers (ptrdiff_t) to Win APIs expecting an int. Patch here: <https://github.com/boostorg/locale/issues/42> Using this command with the recent 1.71.0 beta: call .\bootstrap.bat --without-python .\b2 --without-python toolset=msvc-14.2,msvc-14.0,msvc-12.0,msvc-10.0 runtime-link=shared,static address-model=32,64

2 1

[release] Boost 1.71.0 Beta 1 - déjà vu
by Michael Caisse 23 Jul '19

23 Jul '19

Note: The previous email announcement still had the rc1 tag in the filenames. This version of beta1 is identical in content to beta1 rc1. Boost release 1.71.0 beta 1 is now available at: <https://dl.bintray.com/boostorg/beta/1.71.0.beta1/source/> The SHA256 checksums are as follows: 451adc4f199c73e995e541f38c4dbd51faf4ce0db15537136ffd5213a1be5e55 boost_1_71_0_b1.7z a93d7066fc1514995aec0e726532a219447dd39b0ffa7cb97ca5736f16b0488b boost_1_71_0_b1.tar.bz2 34743b80466463e0c1b7fc71b677f326bdc242fe0b87a9c1599b6f7ea6e5c0cb boost_1_71_0_b1.tar.gz 5cd448bddc8394469391306e0ccada0a8f88c5c6cf8ec775ddf8e56adef8bbc2 boost_1_71_0_b1.zip For details of what's in the release, see <http://www.boost.org/users/history/version_1_71_0.html>. Note: Having some trouble getting the web page updated... check back with it soon. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

2 1

[BOOST] Boost fusion testcase fails with llvm and gcc when optimization enabled
by Jaydeep Chauhan 22 Jul '19

22 Jul '19

Hi Devs, consider below boost testcase, boost_1_70_0/libs/fusion/test/functional/invoke.cpp when compiles with optimization enabled, $g++ -O2 -I./boost_1_70_0 boost_1_70_0/libs/fusion/test/functional/invoke.cpp $./a.out ./boost_1_70_0/libs/fusion/test/functional/invoke.cpp(391): test 'that.data == fusion::invoke(& members::data, fusion::join(sv_obj_c_ctx,seq))' failed in function 'void test_sequence_n(Sequence&, mpl_::int_<0>) [with Sequence = boost::fusion::vector<>]' ./boost_1_70_0/libs/fusion/test/functional/invoke.cpp(401): test 'that.data == fusion::invoke(& members::data, fusion::join(sv_obj_c_d_ctx,seq))' failed in function 'void test_sequence_n(Sequence&, mpl_::int_<0>) [with Sequence = boost::fusion::vector<>]' ./boost_1_70_0/libs/fusion/test/functional/invoke.cpp(391): test 'that.data == fusion::invoke(& members::data, fusion::join(sv_obj_c_ctx,seq))' failed in function 'void test_sequence_n(Sequence&, mpl_::int_<0>) [with Sequence = boost::fusion::list<>]' ./boost_1_70_0/libs/fusion/test/functional/invoke.cpp(401): test 'that.data == fusion::invoke(& members::data, fusion::join(sv_obj_c_d_ctx,seq))' failed in function 'void test_sequence_n(Sequence&, mpl_::int_<0>) [with Sequence = boost::fusion::list<>]' 4 errors detected. And When compiled without any optimization $g++ -O0 -I./boost_1_70_0 boost_1_70_0/libs/fusion/test/functional/invoke.cpp $./a.out No errors detected. $g++ --version Target: x86_64-pc-linux-gnu Configured with: ../gcc-9.1.0/configure -- --enable-languages=c,c++ --disable-libquadmath --disable-libquadmath-support --disable-werror --disable-bootstrap --enable-gold Thread model: posix gcc version 9.1.0 (GCC) Here we demonstrated the test case with g++ but same can be seen with clang++. When analyzed further we have seen that this is [ boost_1_70_0/boost/fusion/functional/invocation/invoke.hpp:139 ] trying to return local address, which is undefined behavior. And that lead to above test-case failure. So either we have to modify test-case to pass as reference or disable it.But before going ahead like to know your thought/suggestions? Thanks, Jaydeep

1 0

Innocent but annoying warning in Boost QVM library
by Luigi Castelli 19 Jul '19

19 Jul '19

Hi Emil and all, when compiling Boost QVM, compilation succeeds but I get this warning: filename: quat_operations.hppwarning: Declaration shadows a typedef in function 'boost::qvm::axis_angle' A declaration in line 1438 shadows one in line 1414 Could this be solved for the next update?Thanks - Luigi

2 1

Boost log to limit log file maximum file size
by JH 19 Jul '19

19 Jul '19

H Andrey and all, Can the log file be configured to set up the file size cap, when the log file reaches to the maximum file size, it deletes it and starts a new log file not rotates it? Thank you. - jupiter

2 1

Lambda testcase fails when optimization enabled in gcc and llvm
by navya deepika garakapati 19 Jul '19

19 Jul '19

Hi Devs, consider below reduced testcase from boost lamda. $cat result_of_tests.cpp #include <boost/lambda/lambda.hpp> #include <stdio.h> template<class A, class F> typename boost::result_of<F(A)>::type apply1(F f, A b) { return f(b); } using namespace boost::lambda; int main(int, char *[]) { int one = 1; int d= (apply1<int>(_1 ,one) == 1); printf("\n%d\n",d); return 0; } when compiled with optimization O2 $g++ result_of_tests.cpp -I ./boost_1_70_0 -O2 $./a.out 0 And,when we compile same testcase with O0 $g++ result_of_tests.cpp -I ./boost_1_70_0 -O0 $./a.out 1 The above testcases is demonstrated with g++ compiler but behavior is same on clang as well. so we thought that this may be boost testcase issue. When we replace , int d= (apply1<int>(_1 ,one) == 1); with int d= (apply1<int&>(_1 ,one) == 1); testcase gives correct result with or without optimization. Wanted to confirm here,is it valid testcase or we have to modify testcase as per above? Thanks, Navya

3 5

Review request for LEAF, review manager needed
by Emil Dotchevski 19 Jul '19

19 Jul '19

I'm requesting a formal review for LEAF, a C++11 error-handling library: https://zajo.github.io/leaf. Features: * Header-only, no dependencies. * No dynamic memory allocations. * Compatible with std::error_code, errno and any other error code type. * Can be used with or without exception handling. LEAF comes complete with its own result<T> type, but it is compatible with any other type with value-or-error variant semantics (like outcome::result<T>) as long as .error() returns a std::error_code. https://travis-ci.org/zajo/leaf https://ci.appveyor.com/project/zajo/leaf

3 2

Re: [boost] [release] 1.71.0 closed for Beta
by Kenneth Porter 19 Jul '19

19 Jul '19

I'm seeing the following block of warnings repeated with several MSVC compiler versions. I'd suggest changing int to ptrdiff_t or size_t for the target type. f:\devel\Boost\boost_1_71_0\libs\locale\src\win32\api.hpp(149): warning C4244: 'argument': conversion from '__int64' to 'int', possible loss of data f:\devel\Boost\boost_1_71_0\libs\locale\src\win32\api.hpp(153): warning C4267: 'argument': conversion from 'size_t' to 'int', possible loss of data f:\devel\Boost\boost_1_71_0\libs\locale\src\win32\api.hpp(153): warning C4244: 'argument': conversion from '__int64' to 'int', possible loss of data f:\devel\Boost\boost_1_71_0\libs\locale\src\win32\api.hpp(170): warning C4244: 'argument': conversion from '__int64' to 'int', possible loss of data f:\devel\Boost\boost_1_71_0\libs\locale\src\win32\api.hpp(245): warning C4244: 'argument': conversion from '__int64' to 'int', possible loss of data f:\devel\Boost\boost_1_71_0\libs\locale\src\win32\api.hpp(249): warning C4244: 'argument': conversion from '__int64' to 'int', possible loss of data My build command: call .\bootstrap.bat --without-python .\b2 --without-python toolset=msvc-14.2,msvc-14.0,msvc-12.0,msvc-10.0 runtime-link=shared,static address-model=32,64

1 0

[release] 1.71.0 closed for Beta
by Michael Caisse 19 Jul '19

19 Jul '19

The master branch is now closed for all changes except by permission for the Beta release. Also, remember to add your libraries' changes to the release notes at: <https://github.com/boostorg/website/blob/master/feed/history/boost_1_71_0.q…> Thanks, -- The Boost Release Team

5 8

Any sample code to configure boost log for syslog?
by JH 18 Jul '19

18 Jul '19

Hi, I am using boost log to write log file in the disk of the desktop, but for an embedded system application where the NAND flash is used, to prolong the flash service life time, I try not to write log files in flash, but use journalctl to view the log in RAM. Are there any simple example to configure boost log for syslog? Thank you. - jh

2 2

Something off my chest about Boost
by Maarten Verhage 18 Jul '19

18 Jul '19

Dear Boost people, Sorry but I need to get something off my chest regarding the Boost culture. To start of with something nice: I’m convinced Boost provides really useful facilities for C++ and some of them even make it into the standard C++ library. I do believe I can also contribute in a reasonable way. But the terse documentation keeps me from advancing. How it is currently stated on https://www.boost.org/users/faq.html “What about documentation? A very simple library might be accepted with only a well commented header file. For more substantial libraries, some form of documentation is certainly going to be expected. HTML is the preferred form.” To make Boost more accessible to people I believe Boost should ask more on this from current and new library authors. Speaking for myself. I think the first bits to get started with a library are on a sufficient level. You know the tutorial and the example code. But I get lost when I want to use the library for my own application domain. Then I do need library facilities not covered in the example code and sometimes the documentation mentions only the syntax. As I would imagine the library author working on his/her library judging whether to add a facility or not. Finally decided to add something: *the thought/motivation that goes along with that*, that would be so valuable for me to read that in the documentation!! Yes, I’m annoyed that I cannot read that in the documentation. Another issue is when example code introduces three or more facilities at once. Then it is very hard for me to see how these bits relate to each other to make it useful for myself. Ok, a few examples for what I would like to ask the Boost community to demand from the library authors: 1) In general, for the classes/functions where the user should directly deal with documentation like cppreference.com. So, with function prototypes showing the argument- and return types and a complete list of members along with what they do. 2) Specifically for Spirit X3, a part on Parser Directives: https://www.boost.org/doc/libs/develop/libs/spirit/doc/x3/html/spirit_x3/qu… I would very much like that the reason why each directive is added along with a minimal example that shows how to use just that directive. Anyway, I hope people are also interested to discus documentation policies on this mailing list. I do believe it is important. Best regards, Maarten Verhage

10 17

ASIO socket termination crashed at boost::asio::async_read
by JH 17 Jul '19

17 Jul '19

Hi, I use boost TCP socket for months, it works well until I call a termination of smart pointer which is running at boost::asio::async_read. Could anyone explain what could be the cause for the following errors? void Comms::HandleReadBody(const boost::system::error_code &error, const uint32_t length) { ................ boost::asio::async_read(this->mHandler->Socket(), boost::asio::buffer(this->mHeader, sizeof(this->mHeader)), [=](const boost::system::error_code &status, const uint32_t length) {this->HandleReadHeader(status, length);}); ............... } (gdb) run 2019-07-15 11:47:32.396184: Sanity check socket connection and terminate it when it is inactive ............. pure virtual method called terminate called without an active exception Program received signal SIGABRT, Aborted. (gdb) backtrace #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 #1 0x00007ffff7a24801 in __GI_abort () at abort.c:79 #2 0x00007ffff5565957 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #3 0x00007ffff556bab6 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #4 0x00007ffff556baf1 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #5 0x00007ffff556c8bf in __cxa_pure_virtual () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #6 HandleReadHeader(boost::system::error_code const&, unsigned int) () #7 0x00007ffff679a116 in boost::asio::detail::read_op<boost::asio::ssl::stream<boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> > >, boost::asio::mutable_buffers_1, boost::asio::detail::transfer_all_t, HandleReadBody(boost::system::error_code const&, unsigned int)::{lambda(boost::system::error_code const&, unsigned int)#1}>::operator()(boost::system::error_code const&, unsigned long, int) () #8 0x00007ffff6799c20 in boost::asio::ssl::detail::io_op<boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >, boost::asio::ssl::detail::read_op<boost::asio::mutable_buffers_1>, boost::asio::detail::read_op<boost::asio::ssl::stream<boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> > >, boost::asio::mutable_buffers_1, boost::asio::detail::transfer_all_t, HandleReadBody(boost::system::error_code const&, unsigned int)::{lambda(boost::system::error_code c---Type <return> to continue, or q <return> to quit--- onst&, unsigned int)#1}> >::operator()(boost::system::error_code, unsigned long, int) () #9 0x00007ffff679b547 in boost::asio::detail::reactive_socket_recv_op<boost::asio::mutable_buffers_1, boost::asio::ssl::detail::io_op<boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >, boost::asio::ssl::detail::read_op<boost::asio::mutable_buffers_1>, boost::asio::detail::read_op<boost::asio::ssl::stream<boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> > >, boost::asio::mutable_buffers_1, boost::asio::detail::transfer_all_t, HandleReadBody(boost::system::error_code const&, unsigned int)::{lambda(boost::system::error_code const&, unsigned int)#1}> > >::do_complete(boost::asio::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code const&, unsigned long) () #10 0x000055555559f5c0 in boost::asio::detail::task_io_service::do_run_one(boost::asio::detail::scoped_lock<boost::asio::detail::posix_mutex>&, boost::asio::detail::task_io_service_thread_info&, boost::system::error_code const&) () #11 0x000055555559f747 in boost::asio::detail::task_io_service::run(boost::system::error_code&) ()

4 5

Useful Release Notes
by James E. King III 13 Jul '19

13 Jul '19

I'd suggest we make sure our release notes are useful to end users; I found some examples that are in the 1.71 that are not useful when reading the notes: * [phrase library..[(a)/libs/flyweight/index.html Flyweight]:] * Maintenance work. * [phrase library..[@/libs/poly_collection/ PolyCollection]:] * Maintenance work. Thanks, Jim

2 1

meeting today
by Robert Ramey 12 Jul '19

12 Jul '19

I was impressed with your presentation today. you can find current renderings at this link: https://we.tl/t-TDoBHgw9AF Robert Ramey

1 1

The out_ptr review is now over
by Zach Laine 11 Jul '19

11 Jul '19

Thanks to all that participated. A review result with be posted sometime in the next couple of weeks (the upcoming C++ standards meeting next week will delay it a bit). Zach

1 0

Failed reconnection
by JH 11 Jul '19

11 Jul '19

Sorry for keeping posting questions about ASIO TCP socket reconnection regarding to network interface changes, I am very much stuck at the moment. As I described in other emails, when one network interface WiFi failed, the network interface Ethernet takes over, the client application using boost ASIO TCP socket cannot detect the broken of WiFi, it continually sent messages to the remote server via the broken WiFi interface without triggering errors but obviously the server could not receive messages any more. So my solution is prior to send message, it ping to 8.8.8.8 via the network interface WiFi, if it failed, it called the SetConnection again to close the socket binding to WiFi interface and to start reconnection to bind to Ethernet interface: void SetConnection(void) { if (this->mSocket.lowest_layer().is_open()) { std::cout << "Set connection close socket" << std::endl; this->mSocket.lowest_layer().close(); } boost::asio::ip::tcp::resolver resolver(this->mIoService); boost::asio::ip::tcp::resolver::query query(this->mHost, this->mPort); this->mIterator = resolver.resolve(query); this->mContext.load_verify_file("ssl/ca.pem"); this->mSocket.set_verify_mode(boost::asio::ssl::verify_peer); this->mSocket.set_verify_callback(boost::bind(&client::verify_certificate, this, _1, _2)); boost::asio::async_connect(mSocket.lowest_layer(), this->mIterator, boost::bind(&client::handle_connect, this, boost::asio::placeholders::error)); } But it did not work, the error: handle_connect connect failed: Network is unreachable What I am missing here? How can I make the TCP socket reconnection? Thank you. Kind regards, - jupiter

2 3

Link problem with graph and pending still appears unresolved?
by pbristow＠hetp.u-net.com 10 Jul '19

10 Jul '19

I have been bitten by this problem, again ☹ error: Cannot create link boost\pending\detail\disjoint_sets.hpp to libs\graph\include\boost\pending\detail\disjoint_sets.hpp. error: Link previously defined to another file, libs\disjoint_sets\include\boost\pending\detail\disjoint_sets.hpp. that was discussed https://lists.boost.org/Archives/boost/2019/04/246083.php I have got going again by deleting the contents of boost/boost/ containing the symlinks. But I note that a folder pending still exists, but not graph. Is this unresolved? Should it be fixed for the next release? Paul Paul A. Bristow Prizet Farmhouse Kendal, Cumbria LA8 8AB UK

5 14

[releaase] 1.71.0 closed for major changes
by Marshall Clow 09 Jul '19

09 Jul '19

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

3 2

Beast repo history changed?
by Tom Kent 09 Jul '19

09 Jul '19

Did something get re-written in the beast repo? I was getting some weird errors on my cron mirror job: error: object file ./objects/3c/5bd5d909ee9b71f2b28d002dfe9d98355766c9 is empty error: object file ./objects/3c/5bd5d909ee9b71f2b28d002dfe9d98355766c9 is empty fatal: loose object 3c5bd5d909ee9b71f2b28d002dfe9d98355766c9 (stored in ./objects/3c/5bd5d909ee9b71f2b28d002dfe9d9835576 6c9) is corrupt error: object file /mnt/fs2/boostorg/beast.git/objects/3c/5bd5d909ee9b71f2b28d002dfe9d98355766c9 is empty error: object file /mnt/fs2/boostorg/beast.git/objects/3c/5bd5d909ee9b71f2b28d002dfe9d98355766c9 is empty fatal: loose object 3c5bd5d909ee9b71f2b28d002dfe9d98355766c9 (stored in /mnt/fs2/boostorg/beast.git/objects/3c/5bd5d909e e9b71f2b28d002dfe9d98355766c9) is corrupt Deleting and re-creating the repo worked fine: git clone --mirror git@github.com:boostorg/beast.git Cloning into bare repository 'beast.git'... remote: Enumerating objects: 296, done. remote: Counting objects: 100% (296/296), done. remote: Compressing objects: 100% (158/158), done. remote: Total 48131 (delta 142), reused 210 (delta 110), pack-reused 47835 Receiving objects: 100% (48131/48131), 35.50 MiB | 24.22 MiB/s, done. Resolving deltas: 100% (33475/33475), done. Not an issue for my just curious/suspicious. Tom

2 1

Contributing to Boost. Astronomy
by Siddhartha Sen 09 Jul '19

09 Jul '19

Hello, I want to get started in contributing to Boost. Astronomy. Could anyone help me out here? This is the first time I will be contributing to open source. Hence I don't have any idea how this works. I am proficient in C and C++ and have a keen interest in Astronomy. Could anyone tell me what all things I need to learn first before I am able to contribute? What documentation should I read or what issues should I be aware of, before I can start contributing? Any help would be appreciated.

3 2

out_ptr formal review
by Gavin Lambert 05 Jul '19

05 Jul '19

My apologies in advance for the light novel. # Do you think the library should be accepted as a Boost library? Not in its current form, although I encourage cleaning it up and resubmitting it. # Your knowledge of the problem domain I've used COM smart pointers (usually CComPtr) a few times, and more rarely wrapped some other C or C-like APIs. (Although mostly pre-C++11, requiring something more hand-rolled than unique_ptr.) # What is your evaluation of the library's: ## Design The API seems reasonable for both out_ptr and inout_ptr. (Although also see the end of this post.) Actual uses for inout_ptr outside of a "realloc" type function seems a bit rare to me (and such APIs also seem rather rare), but perhaps there are other justifying cases I am not aware of, or it's more common in a particular domain. I do like that unspecified function argument evaluation order was considered, and I agree that it is better to try to maintain safety regardless of evaluation order rather than simply telling users to not access the smart pointer in other arguments -- it is a very easy trap for users to fall into, especially where the same code that has been working forever may suddenly fail with a different compiler version or different compiler settings. (Sequencing of destructor execution with additional && conditionals is admittedly a similar problem with no good solution within this design, as is explained in the caveats.) I don't like that it is left unspecified whether release() is called on construction or destruction (as that decision is left to the custom specialisations), as this potentially reintroduces that problem. I think it should be required that all specialisations behave in the following manner: For out_ptr: - construction initialises a raw ptr to nullptr and does not alter the smart ptr. - destruction resets the smart pointer to the raw ptr (in all cases). - this provides a useful guarantee that the smart ptr is always reset to nullptr if the called method returns nullptr, even if it had some other value previously. For inout_ptr: - construction get()s the current value of the smart ptr in two separate raw ptrs (one passed as the function argument, one cached for the destructor to use for comparison), but does not release() it. - destruction will (only if the raw ptr now has some different value) release()s the smart ptr and then reset()s it to the new raw ptr. - this makes it safe to use the smart ptr's value in other arguments of the method call; unspecified release() timing would have made that unsafe. (There is a slightly dodgy step in there where technically the smart pointer could be pointing at something which it thinks it owns, but that the called function has already deleted. However given that any normal or exceptional exit path would then call the inout_ptr destructor [guaranteed before the smart pointer destructor], which would safely release() the pointer without double-deleting it, this seems sufficiently safe, and worth it to permit safe argument usage. The only caveat is that usage of the smart pointer sequenced after the method call but before the destructor execution [as in additional && conditions] is not safe, as it may access deleted memory; however that code would never have the correct behaviour anyway and the documentation already warns to avoid doing that.) Perhaps there are some types of smart pointer for which this contract wouldn't work (eg. if it is possible for release() to fail, or to release a different pointer from what get() returns)? But then if so I'm not convinced it's safe to give them a uniform interface with pointers where it is safe, because otherwise inevitably someone is going to hit the unspecified-parameter-evaluation-order problem (or assuming that it will be nullptr on failure). Especially given these suggested constraints, I would prefer that a simple ADL or traits-type customisation point were added, so that you can adapt to smart pointers which merely have different spellings of the reset and release methods and don't require deeper customisation -- though the existing customisation point could be retained for especially weird smart pointer types if needed. (ADL customisation points are superior because, if designed correctly, they would not introduce a dependency on Boost.OutPtr, and if named well could theoretically also be used by other libraries, as with non-member begin and swap.) Similarly, while the static_assert check in base_out_ptr_impl specifically for std::shared_ptr and boost::shared_ptr seems valuable to prevent a significant class of bugs, I question whether it might be better handled by checking a type trait or other customisation point rather than checking directly for those types, such that it would be possible for a user-defined smart pointer type to also participate if it has a similar concern. Or perhaps it should just discourage use of shared_ptr at all; there should be little performance difference between using shared_ptr directly and using a unique_ptr which is later moved to a shared_ptr. (Since neither can take advantage of the make_shared optmisation, and by definition ownership must be unique at that point.) ## Implementation I haven't verified whether the current implementation exactly follows my suggested contract above, as there are a few too many layers of indirection and inheritance for me to easily parse. Simplifying the implementation would be nice if possible, especially for out_ptr, to improve readability. (However I think that my description is close at least.) I am strongly opposed to both of the "clever" implementations in the library. They should be completely removed. I can think of absolutely no justification (performance or otherwise) for a "clever" out_ptr. Due to both the requirement to pass in nullptr and to not delete the original smart pointer on construction (as it might be used in other parameters), the raw pointer can never have the same storage as the smart pointer anyway. (At least not unless you absolutely promise to never use a non-nullptr smart pointer, which reduces usefulness, albeit admittedly for a slightly peculiar use case [which would have been unsafe when used with raw pointers directly].) (In theory you could pass in an uninitialised raw pointer and then conditionally reset or do nothing depending on whether it still has the same uninitialised value after the call, but this both requires capturing the actual value at construction and providing a weaker contract to the C API, so it seems like a bad idea and a pessimisation to me. Another option is to unconditionally reset() on construction, but this sacrifices use in other parameters.) There is a possible justification for the clever inout_ptr, in that you can save two raw pointer copies if you reuse the smart pointer's storage, and this does not have the same caveats as with out_ptr. I am not convinced that anyone should care about that (especially in code paths also including memory allocation), although it is possible that the savings may be more significant with a smart pointer more complex than unique_ptr. Having said that, this "clever" implementation should absolutely never be used for any existing smart pointer, especially including std::unique_ptr or boost::movelib::unique_ptr. If there is sufficient justification for its existence at all, then you should instead create a new smart pointer (bikeshed: boost::out_ptr::fast_ptr) which behaves equivalent to std::unique_ptr except that you can steal its raw pointer storage when using inout_ptr. This could be made move-compatible with std::unique_ptr for the people who want to keep that type in their interfaces -- although that would presumably also remove any dubious performance benefit. As previously brought up in a separate thread, the current review implementation also leaks public inheritance of std::tuple, which is presumably intended as an empty-base optimisation, but must not be public or it will allow inappropriate slicing (and Very Bad Things™). ## Documentation The documentation seems decent, although being split into many short pages as at present can at times make it harder to locate something specific. I would prefer longer single pages divided into sections, but that's a matter of taste and not a review condition. I dislike the assertion that a "well-designed" C API would always set the parameter to nullptr on failure. That is certainly one option (and typically a preferred one), but leaving the parameter unchanged is another entirely reasonable option, and does not signify "poor design". It is only reasonable to claim poor design if the API allocates and sets the value, internally deletes it, and then reports failure (while still returning the altered and deleted pointer), as this condition cannot be handled by out_ptr (or indeed by anything that doesn't understand the failure return semantics of the API). The time axis scale in the benchmarks seems not entirely helpful as a lot of the time the difference between two implementations is within one axis division of each other. And again, the magnitude of performance difference sitting in the <1ns range in code which inherently implies memory allocation suggests a severe case of premature optimisation to me. (Though perhaps that might be more justifiable when used in non-memory handle contexts -- but then that might be an abuse of calling it a "pointer".) ## Usefulness I think that this library or something like it could be quite useful to help unify and improve safety when interacting with C-style T** APIs (or T* output arguments for some opaque handle type that requires cleanup), without requiring exploitation of operator& tricks like CComPtr does. (Sure, it's trivial to write an RAII wrapper around such APIs, but this can become cumbersome when there are hundreds or thousands of such APIs, unless you're using a code generator. And it's easy to accidentally forget subtle but important things such as deleting copy operations.) # Did you try to use the library? With what compiler? Did you have any problems? I did not try it. However the "clever" implementation is highly compiler-and-library-specific and quite aside from its design issues I think it would also produce significant portability issues. # How much effort did you put into your evaluation? I spent several hours on this review over the course of several days, and some related prior discussion in the mailing list. I read through all the documentation and most of the code (though not the tests). ============================ Having said all of the above, I wonder whether the library author has considered a different design for this functionality? Rather than the given example code: using bop = boost::out_ptr; boost::shared_ptr<mll_driver> axis_driver(nullptr); mll_errno err = mll_driver_init( bop::out_ptr(axis_driver, mll_driver_free), /* additional args ...*/); if (err != MLL_SUCESS) { // ... } A wrapping lambda syntax could be used instead: boost::shared_ptr<mll_driver> axis_driver(nullptr); mll_errno err = bop::invoke( [&](mll_driver** p) { return mll_driver_init(p, /* additional args ...*/); }, bop::out_ptr(axis_driver, mll_driver_free)); if (err != MLL_SUCESS) { // ... } Here, rather than its current meaning, bop::out_ptr just defines a parameter grouping which is then turned into a raw pointer-pointer argument for the lambda; it has no destructor-based shenanigans. (This could also be used for other non-pointer argument types -- there just needs to be a way for invoke to query the expected API argument type from the out_ptr or from the lambda itself.) This is admittedly more verbose than the current design (although bop::invoke could be written as just "invoke" due to ADL, for a slight simplification); but it would allow you to more safely control the sequencing between the API call and the reassignment of the smart pointer -- in particular all of the existing caveats with order of evaluations and with if-statement and composite conditional ordering no longer apply. (You can safely "&& axis_driver" above as long as you do it outside of the invoke call.) The API would be called (via the lambda) from a try-catch block inside of bop::invoke (or instead of the try-catch an RAII helper can be used to perform a try-finally action), and either the existing guarantee of not calling reset() or release() until after the call can be maintained (thereby allowing the smart pointer to be used by reference within the lambda), or it could be forbidden to use the smart pointer inside the lambda and the caller could lambda-capture the necessary arguments by value instead. Either way, the caller should be less surprised about lifetime issues across a lambda "border", and would quickly discover if they did it "wrong" (because the reset/release would either always occur before or always occur after argument evaluation, never in mixed order). invoke would normally be called with only one out_ptr or inout_ptr argument (and consequently one argument to the lambda), but could in principle be extended to any number of arguments either by nested invoke calls or by supporting a variadic form which does the equivalent within the library. It could possibly also be extended to support user-defined argument types to do something more complex, by defining a concept interface that it uses to interact with the argument, rather than explicit overloads or specialisations on those specific types. This could leave the decision of when to reset/release up to the smart-pointer-specific specialisation (if that's useful for performance reasons), and without leaving any time bombs for the caller.

1 0

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 Version 1.47 not building with 2017.
by nunna, sarath babu (GE Healthcare) 03 Jul '19

03 Jul '19

Hello, 1.47 boost is not being built with VS2017. We want to get boost 1.47 built with VS2017, So that we can integrate them with our VS2017 code base. Please guide us, it will be a great help. Thanks, Sarath.

4 9

Boost compatibility/communication issue with 1.47 to 1.7
by nunna, sarath babu (GE Healthcare) 03 Jul '19

03 Jul '19

Hello All, So far we have used Boost 1.47 VS2010 built binaries integrated with our VS2010 Code Base . But now we are upgrading VS2010 to VS2017 of our product code base, also we tried Boost 1.70 boost built using VS2017 and integrated with our VS2017 code base. Our product should be compatible with older versions of all tools including boost. We have not faced any issues except boost. Issue: 1.7 boost is not able to communicate to 1.47 boost and giving "SERIALIZATION ERRORS". 1.47 boost is not able to communicate with 1.7 boost and giving "SERIALIZATION ERRORS". Please help us and let us know which boost version we could upgrade that can be compatible with 1.47. Note: The customer is already using 1.47 2010 boost binaries with built VS2010 product which we can't change. Please suggest us the resolution or the version that we should use. Thanks, Sarath.

4 4

Construction of /defaultlib:XXX for boost::python
by Kacvinsky, Tom 01 Jul '19

01 Jul '19

I discovered while using boost 1.69 with Python 2.7 that a /defaultlib:XXX directive for the boost::python import library is injected into each object file that uses boost::python header files. What I have not been able to figure out is the magic for doing this. I presume it is a macro that makes a #pragma for default libs based on the threading model, the address model, the version of Python in use, and the _MSC_VER compiler macro. Am I am on the right track? Where would this code be? I could find it via searching for #\w?pragma in the code base. Thanks, Tom

2 1

out_ptr review
by Glen Fernandes 30 Jun '19

30 Jun '19

[Edit: Some changes for clarity within, as it was pointed out on Slack that some of the phrasing is confusing. Also updated subject.] Many thanks to JeanHeyd for going through the Boost review process, and to Zach for managing the review. Briefly: I cannot justify acceptance for out_ptr just yet in its current form. I hope to see it return for a new review if the feedback from this review shapes the design so that some of these concerns are resolved. Second: This excludes "inout_ptr" (for which I had even more concerns) and just covers "out_ptr" which is the simpler and more common use case of the two. Below when comparing "what happens under the hood" with out_ptr against the hand written code that a user would write to use a typical C out-pointer API with smart pointers, this is what I'm comparing: [Typical code user would write to use a smart pointer]: Type* raw; Result result = TheCApi(args..., &raw); if (!Success(result)) { // failure (e.g. return, or branch and handle error) } Smart<Type, Deleter> smart(raw, etc...); [What would happen under the hood when using out_ptr]: /* First, 'smart' already has to exist here before TheCApi is called. Either as Smart<Type, Deleter> smart; or Smart<Type, Deleter> smart(nullptr, etc...); depending on deleter */ /* User writes: Result result = TheCApi(args..., out_ptr(smart)); or Result result = TheCApi(args..., out_ptr(smart, etc...)); depending on deleter */ Type* raw = nullptr; Result result = TheCApi(args..., &raw); if (raw != nullptr) { smart.reset(raw); // or smart.reset(raw, etc...); depending on deleter } if (!Success(result)) { // failure (e.g. return, or branch and handle error) } Concern 1. Having to define the smart pointer before TheCApi is called. Ordinarily this might be fine for some smart pointers and stateful deleters, but it may not be fine or desirable for others (depending on the deleter, and depending on the use case). Concern 2. The original user code initializes the smart pointer based on Success(result). The out_ptr version does so based on whether the raw out pointer was changed to something non-null by TheCApi. This might be fine for some cases, but it may not be for others. That it isn't the same as fundamental logic as the user code bothers me, though. Concern 3. The equivalent of the hand written user code is less overhead. Personally I'm of the opinion that this doesn't matter too, but here the author does say he has users who cannot abide by it, and that this facility needs support from e.g. std::unique_ptr to be viable. I'm not a fan of needing unique_ptr implementations to add support for this to make it comparable to some user's hand written code (And this also leads to concern 4 below). Concern 4. The UB optimization that the author wrote because of Concern 3 is a real concern to him. The UB optimization has no place in Boost, and one of which doesn't even work with many C++ library vendors' unique_ptr. (Fortunately the Boost reviews have already echoed this sentiment and I believe this is going away). Concern 5. Supporting other custom smart pointers requires effectively re-implementing out_ptr_t by specialization. I have come to see this as not viable. (Already mentioned in other reviews, and I echo this.) Concern 6. C APIs where the deleter (its state, logic, etc.) are governed by some other result from TheCApi. This is can be worked around in many cases, but the workaround is clumsy. Or insupportable, in other cases. i.e. The stateful deleter in the example above is always initialized with 'etc...' either before-hand via Smart<Type> smart(nullptr, etc...) or at call site with: TheCApi(args, out_ptr(etc...)); before analyzing other results of calling TheCApi. [Concern 7. This concern I had made notes about pre-review has already been eliminated, when the unconditionally noexcept destructor is now only conditionally noexcept.] Other thoughts: The suggestion by Emil lead to an interesting alternative idea to this problem domain, but I had no time to fully explore it. I don't think it would address all of these concerns. It has some other greater appeal, e.g. a way to call C APIs that materializes the smart pointers as results (along with C API return value) of an "Invoke-style" thing. Or even a way to transform a C API with out-pointers into a C++ callable that returns smart pointers (along with C API return value) via a "Bind-style" thing. Glen

2 1

out_ptr's formal review starts now!
by Zach Laine 30 Jun '19

30 Jun '19

Dear Boost community, The formal review of JeanHeyd Meneide's out_ptr library starts Sunday, June 16th and ends on Wednesday, June 26th. 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). Online docs can be found here: https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr.adoc The GitHub repository is available here: https://github.com/ThePhD/out_ptr Also, there is an associated standards proposal: https://thephd.github.io/vendor/future_cxx/papers/d1132.html We encourage your participation in this review. At a minimum, please state: - Whether you believe the library should be accepted into Boost - Your name - Your knowledge of the problem domain You are strongly encouraged to also provide additional information: - What is your evaluation of the library's: * Design * Implementation * Documentation * Tests * Usefulness - Did you attempt to use the library? If so: * Which compiler(s)? * What was the experience? Any problems? - How much effort did you put into your evaluation of the review? All issues discussed during this review will be tracked on the library's GitHub issue tracker at https://github.com/ThePhD/out_ptr/issues. Regards, Zach Laine

11 31

out_ptr review
by David Sankel 29 Jun '19

29 Jun '19

# Whether you believe the library should be accepted into Boost No. Not until some of the major issues are addressed. # Your name David Sankel # Your knowledge of the problem domain I've had to wrap C APIs on multiple occasions. # What is your evaluation of the library's: ## Design The design of the `out_ptr` type is reasonable as a shorthand for calling certain C APIs. In my experience a use case for `in_out_ptr` has never come up. Given the subtleties of its correct (and likely rare) usage, I'd be in favor of leaving this out of the library altogether. Especially given that the semantics of when 'release()' is called are not specified. I agree with the other comments that the customization point is not minimally complete. Ideally a customization point would not require one to replicate all the functionality of the class I'm customizing and, instead, only require a few general purpose functions that that interface can make use of. ## Implementation There are two implementations of `out_ptr`. The one called "clever" invokes undefined behavior as a means to squeeze out some extra performance. I do not think the performance overhead of using this library with the "non clever" implementation justifies the potential portability and and other risks associated with depending on undefined behavior working a particular way. It looks like "clever" mode was #ifdef'ed out, but removing it as cruft would improve maintainability of the implementation and remove the complexity of having an additional `core_out_ptr_t` class. The provided implementation works for smart pointers that follow conventions like the standard, but has some additional logic if the types happen to be `std::shared_ptr` or `boost::shared_ptr`. This hard coded special casing won't work with, say, a company specific shared pointer implementation. This relates to my earlier comment that the customization point should be simplified. ## Documentation The recommendation in the "caveats and caution" to not use out_ptr outside if/else conditionals goes a bit far in my opinion. It is common practice to make function calls that emit failure with return codes in conditionals, as in: ``` if (SQLITE_OK != sqlite3_open("test.db", boost::out_ptr::out_ptr(database, sqlite3_close))) { std::cout << "Problem opening the file"; } ``` For these cases it is safe to use `out_ptr` so I'd suggest rewording the recommendation to allow calls like this. "Almost all well-designed C APIs will set the user-provided output pointer argument to NULL/nullptr upon invalid parameters". This is a very difficult claim to make (what's the sample size?). I'd suggest changing "Almost all" to "Many". I don't understand what the issue is here with APIs not setting the out parameter on failure (which IMO is good practice especially as it relates to strong exception safety guarantees). These APIs have return codes that need to be inspected anyway. The reference documentation reads like a specification rather than what I would typically consider reference documentation. I'd expect to see it written with an intended audience of a casual user with examples and an organization that would be helpful for this reader (e.g.: purpose, description, examples, details) ## Tests The tests look reasonable and comprehensive although there seems to be some `#if 0` conditions that could either be cruft or perhaps the intent is the developer would manually change those to verify compilation failure. The tests are using the 'catch' library which is intended to be a submodule. Is there a precedence for using a third party library like this? For folks using Boost it could be painful to get another dependency approved to run all the Boost tests. It would be preferable IMO to use Boost.Test or something self contained. ## Usefulness I attempted to use the library with g++ 8.3.0 and clang 8.0.0. My example code is below: ```C++ #include <boost/out_ptr.hpp> #include <sqlite3.h> #include <iostream> int main() { std::shared_ptr<sqlite3> database; if (SQLITE_OK != sqlite3_open("test.db", boost::out_ptr::out_ptr(database, sqlite3_close))) { std::cout << "Problem opening the file"; } using Sqlite3Ptr = std::unique_ptr<sqlite3, decltype(&sqlite3_close)>; Sqlite3Ptr database2(nullptr, &sqlite3_close); if (SQLITE_OK != sqlite3_open("test.db", boost::out_ptr::out_ptr(database2, sqlite3_close))) { std::cout << "Problem opening the file"; } } ``` With this `Makefile` ```c++ main : main.cpp g++ -I/home/dsankel/code/out_ptr/include -o $@ $< `pkg-config sqlite3 --cflags --libs` .PHONY: clean clean: $(RM) main ``` I didn't run into any issues. Everything worked okay. I think this library would be handy for wrapping C libraries like sqlite. # How much effort did you put into your evaluation of the review? I spent a few hours on this review. I read through all the documentation, did a cursory review of the code, and came up with the example above. # Minor things * Copyright notices need to have a person's real name to have legal benefits. * In `aout_ptr.adoc` the examples link goes to the overview page. * Some grammar errors in the "C function calls are indeterminately sequenced..." paragraph. * When referring to a Boost library in free flowing text, the correct form is Boost.LibraryName with the same font as the surrounding text.

5 5

out_ptr review is extended until Wednesday, July 10
by Zach Laine 29 Jun '19

29 Jun '19

We don't have enough reviews yet, so we're extending the review by two weeks. Please review this small and useful library! >From the original announcement: The formal review of JeanHeyd Meneide's out_ptr library starts Sunday, June 16th and ends on Wednesday, June 26th. 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). Online docs can be found here: https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr.adoc The GitHub repository is available here: https://github.com/ThePhD/out_ptr Also, there is an associated standards proposal: https://thephd.github.io/vendor/future_cxx/papers/d1132.html We encourage your participation in this review. At a minimum, please state: - Whether you believe the library should be accepted into Boost - Your name - Your knowledge of the problem domain You are strongly encouraged to also provide additional information: - What is your evaluation of the library's: * Design * Implementation * Documentation * Tests * Usefulness - Did you attempt to use the library? If so: * Which compiler(s)? * What was the experience? Any problems? - How much effort did you put into your evaluation of the review? All issues discussed during this review will be tracked on the library's GitHub issue tracker at https://github.com/ThePhD/out_ptr/issues. Zach

5 7

[accumulators] Offer to help with maintenance
by Cromwell Enage 29 Jun '19

29 Jun '19

Hi, everyone! I'm offering to help maintain Boost.Accumulators and have already e-mailed Eric Niebler regarding my intentions. With the deadline for Boost release 1.71 fast approaching, I can take steps to ensure that Boost.Accumulators is in a usable state. I also have a few ideas on how to update and improve Boost.Accumulators (one of them being to make use of variadic templates), but they can wait until after the release for further discussion. Very respectfully, Cromwell D. Enage

1 0

Re: [boost] [logic] Boost::logic (tribool?) actively developed?
by Jacob Lidman 28 Jun '19

28 Jun '19

> It has resently updated to support a change in gcc compilers. So I > would say it's actively maintained. I never asked if it was actively maintained but rather if the library is actively developed, i.e. are new features added, improvements in documentation... > I would say it seems stagnant because it's always been as close to perfection as a > library can be. The reason why the library appear close to perfect is because it clearly has minimal number of features. Improvements can be made to accommodate new needs, e.g. by including other logics. > see https://github.com/boostorg/logic As I mentioned this is the repo for the tribool library, at least that was the name prior to boost 1.70.0

2 1

Some out_ptr concerns
by Glen Fernandes 28 Jun '19

28 Jun '19

Thanks to JeanHeyd for going through the Boost review process, and to Zach for managing the review. Briefly: I do not have enough reasons to recommend acceptance for out_ptr just yet --- in its current form. (I'd like to see it return for a new review when the feedback from this review shapes the design so that some of these concerns are resolved). Second: This excludes "inout_ptr" (for which I had even more concerns) and just focusing on "out_ptr" - which is the simpler and more common use case of the two. Below comparing out_ptr vs the hand written code that a user would write to use a /typical/ C out-pointer API with smart pointers, this is what I'm comparing: [Typical code user would write]: Type* raw; Result result = TheCApi(args..., &raw); if (!Success(result)) { // failure (e.g. return, or branch and handle error) } Smart<Type, Deleter> smart(raw, etc...); [What happens with out_ptr now]: /* 'smart' already has to exist here before TheCApi is called. Either as Smart<Type, Deleter> smart; or Smart<Type, Deleter> smart(nullptr, etc...); depending on deleter */ /* User writes: Result result = TheCApi(args..., out_ptr(smart)); // or Result result = TheCApi(args..., out_ptr(smart, etc...)); depending on deleter */ Type* raw = nullptr; Result result = TheCApi(args..., &raw); if (raw != nullptr) { smart.reset(raw); // or smart.reset(raw, etc...); depending on deleter } if (!Success(result)) { // failure (e.g. return, or branch and handle error) } Concern 1. Having to materialize the smart pointer before TheCApi is called. Ordinarily this might be fine for some smart pointers and stateful deleters, but it may not be for others. Concern 2. The original user code initializes the smart pointer based on Success(result). The out_ptr version would do so based on whether the raw out pointer was changed to something non-null by TheCApi. This might be fine for some cases, but it may not be for others. That it isn't the same as fundamental logic as the user code bothers me, though. Concern 3. The equivalent of the hand written user code is less overhead. Personally I'm of the opinion that maybe this doesn't matter too, but here the author does say he has users who cannot abide by it, and that this facility needs support from e.g. std::unique_ptr to be viable. (And this leads to concern 4 below). [I'm not a fan of needing unique_ptr implementations to add support for this to make it comparable to some user's hand written code]. Concern 4. The UB optimization that the author wrote because of Concern 3 is a real concern to him. The UB optimization has no place in Boost, and one of which doesn't even work with many C++ library vendors' unique_ptr. [Fortunately the Boost reviews have already echoed this sentiment and I believe this is going away]. Concern 5. Supporting other custom smart pointers requires effectively re-implementing out_ptr_t by specialization. I have come to see this as not viable. [Already mentioned in other reviews] Concern 6. C APIs where the deleter (its state, logic, etc.) are governed by some other result from TheCApi. This is can be worked around in many cases, but the workaround is clumsy. Or insupportable, in other cases. i.e. The stateful deleter is always initialized with 'etc...' either before-hand via Smart<Type> smart(nullptr, etc...) or at call site with: TheCApi(args, out_ptr(etc...)); before analyzing other results of calling TheCApi. (The 7th concern I had made notes about pre-review has already been eliminated, when the unconditionally noexcept destructor is now only conditionally noexcept). Other thoughts: The suggestion by Emil lead to an interesting alternative idea to this problem domain, but I had no time to fully explore it. I don't think it would address all of these concerns. It has some other greater appeal, e.g. a way to call C APIs that materializes the smart pointers as results (along with C API return value) of an "Invoke-style" thing. Or even a way to transform a C API with out-pointers into a C++ callable that returns smart pointers (along with C API return value) via a "Bind-style" thing. Glen

1 0

out_ptr -- alternatives
by Andrzej Krzemienski 28 Jun '19

28 Jun '19

Hi Everyone, This is not a review of out_ptr, but I wanted to share my thoughts about the motivation for this library. I do not recall any time from my programming experience where I was in need of passing a smart pointer to a T** interface, so maybe this is why I cannot appreciate the value of out_ptr. On the other hand, if I need to use a library with a C API, or other non-C++ API (this happens when someone wants to naively port a Java library to C++ and keep the Java interface) the first thing I do is to wrap the API functions into a RAII class. It takes some time up front, but then whenever it is used, I do not have to deal with the problems of the old API. `T**` is only one of the problems. The motivation focuses on only easily passing smart pointers to `init(T**)` functions, but it does not address the problem of adapting the error reporting of `init(T**)`to the error reporting of my program. I would never want to only solve the former problem and omit the latter. Also, I would never want to represent a handle to a resource with a smart pointer, as I do not want to voluntarily inject the null-pointer state that I now have to take care of everywhere. Instead I would prefer a dedicated type that is not default-constructible, where one really needs to try hard to get the special no-resource state (e.g. by moving from and not destroying the object). What I am missing from the motivation of out_ptr is the comparison with a full RAII wrapper solution. You can argue that the scope of out_ptr is just different: provide interpoperation between `init(T**)`functions and smart pointers. But I would argue that this latter goal is wrong. In fact, I am concerned that we might be encouraging a bad programming style: "need to work with init(T**) APIs? use shared_ptr." instead of promoting RAII wrappers that directly wrap the resource. Does anyone else feel the same? Or am I missing something about the problem domain? Anyway, I think that this problem should be covered in the documentation. Regards, &rzej;

6 8

[logic] Boost::logic (tribool?) actively developed?
by Jacob Lidman 27 Jun '19

27 Jun '19

Hi, Is boost::logic actively developed and if so what are the future plans for the library? >From the source/documentation it seems to be dormant since ~2004 and a renaming of the tribool package. The latter is listed as a library on the boost homepage but lack a library repo on github.com/boostorg (?). BR /Jacob

2 1

ASIO TCP connection switch
by JH 27 Jun '19

27 Jun '19

Hi, I have an application using ASIO TCP/IP SSL socket connection in an embedded device, the device has two network interfaces, when one is down, another network interface takes over, which requires application TCP SSL socket connection to be established binding to a new network interface. What will be an appropriate implementation to switch application TCP connection from one to another interface? Option 1: Restart application Option 2: Terminate the old interface socket, create a new socket to start initial connection Option 3: Some reconnection method which I don't know Appreciate you advice. Thank you. Kind regards, - jupiter

3 4

Can boost ASIO socket binding to any interfaces or support QUIC?
by JH 27 Jun '19

27 Jun '19

Hi, I posted a similar question in another email but title was not appropriate, let me try it here using a more accurate clear title. I might need separate it into email questions, I am not quite clear it is boost socket nature or it is NAT issue. I have both client server applications using boost asio TCP socket, the client application is a Linux embedded system IoT device installed in home connect to server via NAT, the embedded system has two network interfaces, WiFi and cellular, in anytime there is only one network interface is up ans signed by an IP address, when one interface is down, another interface is up and signed IP address. The problem for an existing TCP socket connection is it cannot change from one interface to another. When one interface down another interface takes over, the client application continual sends data to the down interface buffered in TCP queue without transmission error but the server would never receive the data. It seems the only solution is to use QUIC, hence I asked here if there is any boost functions to support QUIC I can replace the TCP socket by QUIC. Appreciate your advice and tips. Thank you. Kind regards, - jupiter

1 0

[build] Build errors with gcc - bad argument -mcpu=v7
by Andrey Semashev 26 Jun '19

26 Jun '19

Hi, I'm trying to run tests for Boost.Core with the following command: bjam -j 8 toolset=gcc cxxstd=14 variant=release libs/core/test Compilation fails with the following errors: gcc.compile.c++ bin.v2/libs/core/test/lightweight_test_fail10.test/gcc-8/release/cxxstd-14-iso/threading-multi/visibility-hidden/lightweight_test_fail10.o g++: warning: ‘-mcpu=’ is deprecated; use ‘-mtune=’ or ‘-march=’ instead cc1plus: error: bad value (‘v7’) for ‘-mtune=’ switch cc1plus: note: valid arguments to ‘-mtune=’ switch are: nocona core2 nehalem corei7 westmere sandybridge corei7-avx ivybridge core-avx-i haswell core-avx2 broadwell skylake skylake-avx512 cannonlake icelake-client icelake-server bonnell atom silvermont slm knl knm intel x86-64 eden-x2 nano nano-1000 nano-2000 nano-3000 nano-x2 eden-x4 nano-x4 k8 k8-sse3 opteron opteron-sse3 athlon64 athlon64-sse3 athlon-fx amdfam10 barcelona bdver1 bdver2 bdver3 bdver4 znver1 btver1 btver2 generic native "g++" -std=c++14 -fvisibility-inlines-hidden -fPIC -m64 -pthread -O3 -finline-functions -Wno-inline -Wall -fvisibility=hidden -mcpu=v7 -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I"." -c -o "bin.v2/libs/core/test/lightweight_test_fail10.test/gcc-8/release/cxxstd-14-iso/threading-multi/visibility-hidden/lightweight_test_fail10.o" "libs/core/test/lightweight_test_fail10.cpp" ...failed gcc.compile.c++ bin.v2/libs/core/test/lightweight_test_fail10.test/gcc-8/release/cxxstd-14-iso/threading-multi/visibility-hidden/lightweight_test_fail10.o... I'm not sure where that -mcpu=v7 comes from, but I don't have it in my options, nether do I see it in the Jamfile.

2 2

[release] 1.71.0 closed for new libraries and breaking changes
by Michael Caisse 26 Jun '19

26 Jun '19

The master branch is now closed for new libraries and breaking changes, and will be closing for major changes in a week and closed for the beta in two weeks. Also, if you're ready, you can also add your libraries' changes to the release notes at: <https://github.com/boostorg/website/blob/master/feed/history/boost_1_71_0.q…> Thanks, -- The Boost Release Team

1 0

Boost 1.54 build integration errors in VS2017
by nunna, sarath babu (GE Healthcare) 26 Jun '19

26 Jun '19

HI, I am getting below error when I tried to integrate boost 1.54 version into our project using VS2017. error C3861: 'assert_arg': identifier not found error C2039: 'assert_arg': is not a member of 'boost::mpl' I am not able to fix this error. Hence, Please provide me help to get rid of this error. Thanks, Sarath.

2 1

IP TCP connections asio::ip::tcp::socket
by JH 25 Jun '19

25 Jun '19

Hi, I am running an application using boost ASIO IP/TCP socket to connect Internet. I have two network interfaces, when one is down, it switches to another one, in my application

1 0

[boost-ci] Added support for building big-endian on Travis CI
by James E. King III 24 Jun '19

24 Jun '19

You can now run a big-endian build job on Travis CI through some docker magic. I had an endian bug in some relatively new code in Boost.UUID (in the MD5 hasher) that required a big endian environment to build in and test with, so I had to solve this impediment. The Boost Docker Development Environment (BDDE) was taught how to build and run multiarch images. At this point I'd like to consider having BDDE move into boostorg alongside boost-ci. It provides an easy way to hop into or run boost builds inside docker containers. One of the examples is to run a predef unit test in the arm64 or ppc64 containers and see how predef defines the macros. Following that, Boost-CI was taught how to use BDDE under Travis CI to run a build in one of the containers. When running the red-ppc64 image expect a slowdown in the 10x to 20x range. If you are concerned about build time on Travis CI (maximum length 50 minutes), I would recommend running a subset of tests. Even building b2 (bootstrap) takes more than a minute. Building Boost.UUID with tests takes about 25 minutes (this includes building some of Boost.Serialization). You can also use BDDE directly to build the same way on a docker-enabled development system. I wasn't able to run gdb in this environment when the architecture was ppc64, but I could build and run tests. gdb works on the x86_64 docker container. Boost-CI: https://github.com/boostorg/boost-ci BDDE: https://github.com/jeking3/bdde Example PR that enables it on Travis CI: https://github.com/boostorg/uuid/pull/109 Enjoy, - Jim

1 0

Serialization Issue found in 1.69 and 1.70 of boost libraries
by nunna, sarath babu (GE Healthcare) 24 Jun '19

24 Jun '19

Hello, We use boost libraries in our project. We had no issues found in 1.47 version in our product.(In Windows 7) But we wanted to upgrade to latest version into Windows 10 environment. We have got issues with serialization. Please let us know in which version you have introduced serialization above than 1.47 version? So that we will take one version below than that or let us know whether have to include/modify anything to adopt latest 1.69 or 1.7 version of boost. Your response will be a great help to us. Thanks, Sarath.

2 1

[build] Option to have b2 show stdout from target run?
by James E. King III 24 Jun '19

24 Jun '19

Currently b2 only shows output when a test fails unexpectedly. If I want to build and run a test and see the stdout from the test all in one command, is there a b2 option that would do that? For example, the output from predef's "info_as_cpp" test is useful, and I'd like to have a single command line that builds it, runs it, and shows stdout. I don't see a way to do this with b2, even with the -d+n flags. I can do it this way, but it's fragile: $(b2 -a -ox info_as_cpp | grep 'gcc.link' | cut -d' ' -f2) - Jim

3 2

B2 release 4.0.0
by Rene Rivera 24 Jun '19

24 Jun '19

After even more years of development the landscape of build systems has changed considerably, and so has the landscape of compilers. This version marks the start of B2 transitioning to a C++ implementation. Initially this means that the engine will be compiled as C++ source but that source is still the base C implementation. Over time it will transform to a C++ code base in both the engine and build system. Some changes in this start: - Requires C++ 11 to build engine. - Simplified build scripts to make it easier to maintain. - Building with C++ optimizations gives an immediate performance improvement. *Other changes in this release:* - Add support for using prebuilt OpenSSL. -- *Damian Jarek* - Define the riscv architecture feature. -- *Andreas Schwab* - Add ARM64 as a valid architecture for MSVC. -- *Marc Sweetgall* - Set coverage flags, from coverage feature, for gcc and clang. -- *Damian Jarek* - Add s390x CPU and support in gcc/clang. -- *Neale Ferguson* - Support importing pkg-config packages. -- *Dmitry Arkhipov* - Support for leak sanitizer. -- *Damian Jarek* - Fix missing /manifest option in clang-win to fix admin elevation for exes - with "update" in the name. -- *Peter Dimov* - Add freertos to os feature. -- *tee3* - Default parallel jobs (-jX) to the available CPU threads. -- *Rene Rivera* - Simpler coverage feature. -- *Hans Dembinski* - Better stacks for sanitizers. -- *James E. King III* *WARNING*: The default number of parallel jobs has changed in this release from "1" to the number of cores. There are circumstances when that default can be larger than the allocated cpu resources, for instance in some virtualized container installs. *Continuously tested on:* - Linux Clang 3.5, 3.6, 3.7, 3.8, 3.9, 4, 5, 6, 7, 8 - Linux GCC 4.7, 4.8, 4.9, 5, 6, 7, 8, 9 - macOS Xcode 8.3.3, 9.0, 9.0.1, 9.1, 9.2, 9.3, 9.3.1, 9.4, 9.4.1, 10.0, 10.1, 10.2, 10.2.1 - Windows MinGW 8.1.0 - Windows VS 2013, 2015, 2017, 2019 Documentation and more at <https://boostorg.github.io/build/> -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

2 2

Re: [boost] [Boost-testing] Test Failures on develop
by Tom Kent 24 Jun '19

24 Jun '19

On Fri, Jun 21, 2019 at 5:11 AM Tom Kent <lists(a)teeks99.com> wrote: > > > On Thu, Jun 20, 2019, 10:35 PM Rene Rivera <grafikrobot(a)gmail.com> wrote: > >> On Thu, Jun 20, 2019 at 10:28 PM Tom Kent <lists(a)teeks99.com> wrote: >> >>> >>> On Thu, Jun 20, 2019 at 7:15 AM Rene Rivera <grafikrobot(a)gmail.com> >>> wrote: >>> >>>> Since it's not due to the b2 -j change.. >>>> >>>> On Fri, Jun 14, 2019 at 8:25 AM Tom Kent via Boost-Testing < >>>> boost-testing(a)lists.boost.org> wrote: >>>> >>>>> For the last few days (Since June 4?) I've been having problems with >>>>> all my linux tests running against the develop branch. >>>>> >>>>> GCC ends with this: >>>>> >>>>> gcc.compile.c++ ../../bin/common/build/gcc-8/release/process_jam_log.o >>>>> >>>>> "g++-8" -fPIC -O3 -finline-functions -Wno-inline -Wall >>>>> -DBOOST_ALL_NO_LIB=1 -DNDEBUG -D_CRT_SECURE_NO_WARNINGS - >>>>> I"/var/boost/run/boost_root" -c -o >>>>> "../../bin/common/build/gcc-8/release/process_jam_log.o" >>>>> "../../common/build/../src/p >>>>> rocess_jam_log.cpp" >>>>> >>>>> ../../common/build/../src/process_jam_log.cpp: In function >>>>> 'std::__cxx11::string {anonymous}::revision(const string&)': >>>>> ../../common/build/../src/process_jam_log.cpp:359:16: warning: >>>>> ignoring return value of 'int system(const char*)', decla >>>>> red with attribute warn_unused_result [-Wunused-result] >>>>> std::system("git rev-parse --short=6 HEAD >.short-sha"); >>>>> ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>>> ...skipped <p../../bin/testing/build/gcc-8/release>process_jam_log for >>>>> lack of <p/var/boost/run/boost_root/bin.v2/libs/f >>>>> ilesystem/build/gcc-8/release/link-static/visibility-hidden>libboost_filesystem.a... >>>>> >>>>> >>>> >>>> I guess you'd need to find out what it says for trying to build >>>> filesystem lib. >>>> >>> >>> Here's what I'm seeing with the filesystem error: >>> >>> ln -f -s >>> "../../libs/detail/include/boost/detail/has_default_constructor.hpp" >>> "../../../boost_root/boost/detail/has_ >>> default_constructor.hpp" >>> >>> gcc.compile.c++ >>> /var/boost/run/boost_root/bin.v2/libs/filesystem/build/gcc-8/release/link-static/visibility-hidden/path_traits.o >>> >>> "g++-8" -fvisibility-inlines-hidden -m64 -O3 -finline-functions >>> -Wno-inline -Wall -fvisibility=hidden -DBOOST_ALL >>> _NO_LIB=1 -DBOOST_FILESYSTEM_STATIC_LINK=1 -DNDEBUG >>> -I"/var/boost/run/boost_root" -c -o "/var/boost/run/boost_root/bin. >>> v2/libs/filesystem/build/gcc-8/release/link-static/visibility-hidden/path_traits.o" >>> "/var/boost/run/boost_root/libs/file >>> system/src/path_traits.cpp" >>> >>> /var/boost/run/boost_root/libs/filesystem/src/path_traits.cpp:20:10: >>> fatal error: boost/filesystem/config.hpp: No such f >>> ile or directory >>> #include <boost/filesystem/config.hpp> >>> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> compilation terminated. >>> ...failed gcc.compile.c++ >>> /var/boost/run/boost_root/bin.v2/libs/filesystem/build/gcc-8/release/link-static/visibility-hidden/path_traits.o... >>> gcc.compile.c++ >>> /var/boost/run/boost_root/bin.v2/libs/filesystem/build/gcc-8/release/link-static/visibility-hidden/portability.o >>> >>> "g++-8" -fvisibility-inlines-hidden -m64 -O3 -finline-functions >>> -Wno-inline -Wall -fvisibility=hidden -DBOOST_ALL >>> _NO_LIB=1 -DBOOST_FILESYSTEM_STATIC_LINK=1 -DNDEBUG >>> -I"/var/boost/run/boost_root" -c -o "/var/boost/run/boost_root/bin. >>> v2/libs/filesystem/build/gcc-8/release/link-static/visibility-hidden/portability.o" >>> "/var/boost/run/boost_root/libs/file >>> system/src/portability.cpp" >>> >>> /var/boost/run/boost_root/libs/filesystem/src/portability.cpp:20:10: >>> fatal error: boost/filesystem/config.hpp: No such f >>> ile or directory >>> #include <boost/filesystem/config.hpp> >>> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> compilation terminated. >>> ...failed gcc.compile.c++ >>> /var/boost/run/boost_root/bin.v2/libs/filesystem/build/gcc-8/release/link-static/visibility-hidden/portability.o... >>> >>> >>> And several more like that. >>> >>> However, I'm also suspicious of the timing with the processor change. >>> >>> Looking back at the last successful builds of develop on linux. I have a >>> few from linux/x86_64/docker machines. The last one I saw was building with >>> gcc-8 on June 4 around 6:30am CDT. There should have been a successful >>> clang run about 5hrs after that (11:30am CDT), and another successful gcc >>> around 10hrs after the last one that was actually successful (4:30pm CDT). >>> >>> This seems like it would correspond to the change to build here: >>> >>> https://github.com/boostorg/build/commit/451059949d92b52b21f802562a50587f1e… >>> >>> The other failure I started seeing was only my linux/arm64 machine. This >>> doesn't run docker, so might not be affected in the same way. The last >>> successful run on there was at 4:50pm CDT on June 4...but it typically >>> takes around 9hrs to run so it probably got the pre 451059949 commit. >>> However here I can't rule out that it was impacted by a8ab76ef973. >>> >>> I'm going to try to standup some normal VMs soon and run on them to see >>> if they are affected in the same way. It would also be nice if we could try >>> backing out the usage of _SC_NPROCESSORS_ONLN and see if that fixes things, >>> is that feasible to try for a couple days? >>> >> >> Again.. It's not a b2 issue. Specifying the "-jX" option entirely >> obviates the changed code. It's almost certainly something else. Places to >> look would be in the filesystem lib, or the root "boost" project for >> changes. >> > > Looking at regression.py it looks like the command that builds > process_jam_log doesn't use the bjam options. Can you verify if this > is/isn't the case? > > Tom > Somewhere between 9:57am and 12:02pm CDT today this bug migrated to master. It can trivially be re-produced. On a bare linux vm...Azure F8s_v2, Ubuntu 18.04, standard SSD. $ sudo apt update && sudo apt install build-essential gcc-8 g++-8 python python3 git wget ... $ wget https://raw.githubusercontent.com/boostorg/regression/develop/testing/src/r… $ echo using gcc : 8 : g++-8 : \; > ~/user-config.jam $ python run.py --runner=teeks99-test01 --toolsets=gcc-8 --tag=develop --bjam-options="-j8 address-model=64" ...fails with the above errors. You can also do the same thing to reproduce in a docker image (ubuntu:bionic). --bjam-options of -j1 -j8 and absent all fail the same. This does not correspond to any changes between the filesystem library that indicates the error. But it *does* correspond exactly with the release of the new B2. https://github.com/boostorg/build/commit/04efaac148671479b514db882b1c520dca… There have been no successful regression tests by any linux runners since that time. Tom

2 2

Release tags request..
by Rene Rivera 24 Jun '19

24 Jun '19

B2 is doing it's own "out of band" (aka independent) releases. In order to avoid confusion.. Can the Boost release process please avoid tagging the build subrepo with the Boost release tags from now on? -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

4 8

[boost-users] [compiler] Boost VC++ 14.2 test compiler
by Alex J 23 Jun '19

23 Jun '19

Hi, Does anybody know when VC++ 14.2 will be added as a 'primary compiler tested' ?. At the moment there is only VC++ 14.1. Thanks

1 0

Travis CI again.
by John Maddock 23 Jun '19

23 Jun '19

Sorry, but I need help, and simply can not see what's going wrong with: https://github.com/boostorg/config/pull/286. Travis doesn't even seem to be building the same code as has been pushed? And until I can get CI functioning again here, and in other libraries, nothing gets merged to master :( Sorry if I'm being dense, and thanks in advance, John. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

3 4

[release] 1.71.0 deadline for new libraries approaching
by Michael Caisse 22 Jun '19

22 Jun '19

One week from today master will closed for new libraries and breaking changes. Thanks, -- The Boost Release Team Boost Calendar with the release schedule: <http://www.boost.org/development/index.html>

3 4

[process][type_erasure] Including both process and type_erasure creates duplicate definitions in mp11 and fusion
by Jared McIntyre 21 Jun '19

21 Jun '19

I've found that type_erasure::any and process::child conflict with each other in how they use mp11 and fusion. The issue may be specific to compiling the process library on Windows as it occurs in calls through detail headers in the library that are specific to Windows, and I haven't tested on other platforms.. #include <boost/type_erasure/any.hpp> #include <boost/process/child.hpp> Order doesn't matter. 1>c:\<removed>\boost\boost\fusion\adapted\std_tuple\tag_of.hpp(38): error C2953: 'boost::mpl::sequence_tag<std::tuple<_Types...>>': class template has already been defined 1>c:\<removed>\boost\boost\mp11\mpl.hpp(155): note: see declaration of 'boost::mpl::sequence_tag<std::tuple<_Types...>>' Boost 1.67, 1.70 VS 2017 (5.9.12)

1 0

[boost-developers] [MSVC142] When is boost going to add MSVC 14.2 as a test compiler
by Alex J 21 Jun '19

21 Jun '19

Hi, I can see that boost has updated their code to support MSVC14.2 builds. However according to latest 1.70 docs, they are not testing on 14.2 compiler. When can we expect boost to include 14.2 as one of their primary test compilers ? Thanks Alex

2 1

Re: [boost] [release] 1.71.0 deadline for new libraries approaching
by Kenneth Porter 20 Jun '19

20 Jun '19

Can we get this fix into the crc library? It fixes a warning in MSVC compilers. <https://github.com/boostorg/crc/pull/2>

1 0

CMake config scripts broken in 1.70
by Alexander Grund 19 Jun '19

19 Jun '19

Hi all, I discovered a severe logic flaw in the generated CMake Config files for the new Boost 1.70 which make them almost unusable. As an example the static variant contains: if(NOT"${Boost_USE_STATIC_LIBS}"STREQUAL""ANDNOTBoost_USE_STATIC_LIBS) _BOOST_SKIPPED("libboost_filesystem.a""static, Boost_USE_STATIC_LIBS=${Boost_USE_STATIC_LIBS}") return() endif() if(BUILD_SHARED_LIBS) _BOOST_SKIPPED("libboost_filesystem.a""static, BUILD_SHARED_LIBS=${BUILD_SHARED_LIBS}, set Boost_USE_STATIC_LIBS=ON to override") return() endif() The shared variant contains: if(NOT"${Boost_USE_STATIC_LIBS}"STREQUAL""ANDBoost_USE_STATIC_LIBS) _BOOST_SKIPPED("libboost_filesystem.so.1.70.0""shared, Boost_USE_STATIC_LIBS=${Boost_USE_STATIC_LIBS}") return() endif() if(NOTBUILD_SHARED_LIBS) _BOOST_SKIPPED("libboost_filesystem.so.1.70.0""shared, BUILD_SHARED_LIBS not ON, set Boost_USE_STATIC_LIBS=OFF to override") return() endif() Although the message text says otherwise the 2nd return in both cases depends solely on BUILD_SHARED_LIBS. I'm pretty sure the intention was too check for BUILD_SHARED_LIBS *only* if Boost_USE_STATIC_LIBS is not set (see thread https://lists.boost.org/Archives/boost/2019/02/245030.php) As can be seen this is not the case. I haven't found the repo which contains the code that generates this so I can't report it there or fix it myself. As the issue here makes using Boost 1.70 (almost) impossible (in Scenarios like BUILD_SHARED_LIBS=ON (a CMake variable influencing the project build) and Boost_USE_STATIC_LIBS=ON) I'd recommend fixing this and pushing out a bugfix release. Regards, Alexander Grund

2 4

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

19 Jun '19

> > >>> 2) How can I test proper support for std::current_exception() and > >>> std::rethrow_exception() if exceptions are disabled for the test? > >> > >> You should probably condition your test on BOOST_NO_EXCEPTIONS and make > >> the test no-op when exceptions are disabled. > > > > But that defeats the whole purpose of having tests. > > Not really. You would still test the facilities when exceptions are > enabled. OTOH, I don't see why would anyone care about these components > when exceptions are disabled. > > If the Jamfile disables exceptions for the library tests, then I think I need to care. Otherwise this config macro would be untested. > > I think I should at least use the type std::exception_ptr, and make sure > > the functions std::current_exception() and std::rethrow_exception() exist > > (even if I cannot test that they actually work as expected at runtime). > > > > I think the following should work, and at least the test tests something > > when exceptions are off: > > > > using std::exception_ptr; > > auto current = &std::current_exception; > > auto rethrow = &std::rethrow_exception; > > > > What do you think? > > If it works, that would be fine by me. I don't disable exceptions and I > don't know whether the standard library components related to exceptions > stay available when exceptions are disabled. I wouldn't be surprised if > they don't (now or in a future version of the standard library > implementation). In any case, as I said, I don't see anyone using these > components when exceptions are disabled, so not much point in testing. > > In the end I settled for using std::exception_ptr; using std::current_exception; using std::rethrow_exception; because some old version of clang had issues with auto, sigh... The problem now is that something else is broken in the CI tests, but I'm quite confident that the tests should pass in all of msvc, gcc, clang I'd like to ask for the PR #285 to be merged into develop please ( https://github.com/boostorg/config/pull/285) Thanks!

1 0

Ticket #9804 - polygon intersection
by Michael Knafo MTH 19 Jun '19

19 Jun '19

Hello ! I have encountered the same problem described in bug #9804: "The result of an intersection is sometimes equal to one of the input polygons, when the result should be empty". https://svn.boost.org/trac10/ticket/9804 Does anyone knows if this bug was fixed and in which boost version ? Is there any version release notes related to this bug ? Alternatively, does anybody know what cause this problem ? Thanks Michael *********************************************************************************************** Please consider the environment before printing this email ! The information contained in this communication is proprietary to Israel Aerospace Industries Ltd. and/or third parties, may contain confidential or privileged information, and is intended only for the use of the intended addressee thereof. If you are not the intended addressee, please be aware that any use, disclosure, distribution and/or copying of this communication is strictly prohibited. If you receive this communication in error, please notify the sender immediately and delete it from your computer. Thank you. Visit us at: www.iai.co.il

2 2

Proposed for inclusion in boost: a C++11 span
by Hans Dembinski 17 Jun '19

17 Jun '19

Dear all, I started to work on a C++11 implementation of std::span. The interface will be an exact mirror of std::span, https://en.cppreference.com/w/cpp/container/span. Having a drop-in replacement of std::span for systems with older compilers in Boost seems like a very good idea. Is anyone else already working on this? I am happy to join forces. Coding down the span took me an hour, but several more hours will go into unit testing and documenting. Best regards, Hans

3 4

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

17 Jun '19

> > > > > However, in my test I throw and catch exceptions: > > But the CI jobs have gcc and clang configured to compile without > exception > > support! > 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 > > It's in the test/Jamfile.v2 file, look for <exception-handling>off. > Thanks! > > > 2) How can I test proper support for std::current_exception() and > > std::rethrow_exception() if exceptions are disabled for the test? > > You should probably condition your test on BOOST_NO_EXCEPTIONS and make > the test no-op when exceptions are disabled. > But that defeats the whole purpose of having tests. I think I should at least use the type std::exception_ptr, and make sure the functions std::current_exception() and std::rethrow_exception() exist (even if I cannot test that they actually work as expected at runtime). I think the following should work, and at least the test tests something when exceptions are off: using std::exception_ptr; auto current = &std::current_exception; auto rethrow = &std::rethrow_exception; What do you think?

2 1

CI: clang installation broken in current Travis build images
by John Maddock 17 Jun '19

17 Jun '19

Currently, pretty much all attempts at installing clang on the travis build images is failing: https://travis-ci.org/boostorg/config/builds/546084433?utm_source=github_st…. And since all the boost libraries have pretty much copied each others .travis.yml files, this means that most PR's for most libraries will be failing. Anyone any ideas? Thanks, John. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

3 2

[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

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

Re: [boost] [variant] tests failing on master
by Nikita Kniazev 30 Apr '19

30 Apr '19

> boost.variant tests are failing on master. Whatever the bug is, it is also causing my signals2 tests that use variant to fail. Config needs develop to master merge to resolve the issue.

1 0

[variant] tests failing on master
by Frank Mori Hess 30 Apr '19

30 Apr '19

boost.variant tests are failing on master. Whatever the bug is, it is also causing my signals2 tests that use variant to fail. -- Frank

1 0

Re: [boost] [variant] Heads-up!
by Nikita Kniazev 29 Apr '19

29 Apr '19

There seems to be misunderstanding of what the thread is about. The short sum-up of the changes: Nothing changed for users that does not use recursive variant. The changes were applied mainly for recursive_wrapper, and affect recursive variant indirectly. The PR was proposed as a solution for two major recursive variant problems: * Move-only types support * Poor move performance (because of this one Spirit has its own variant) Most of the users are not affected by recursive_wrapper move constructor change. To hit it you have to visit (either directly, or with applying comparison operators) a recursive moved-out variant. > have to agree with Steven. Never empty guarantee is a crucial difference between Boost.Variant and std::variant. std::variant has no recursive variant support. In the common field nothing changed. See the comment above. > If the one negative is adding UB to valid existing code at the next point release, doesn't that outweigh any number of positive outcomes? I do not think there even a single user that visits moved-out variants. There is an assertation for such usage though. > Why wouldn't this be an opt-in strategy - this property of moves has been established for years now. Because it solves the bigger problems and for much more users that it potentially breaks.

2 2

[MP11] Loosing const-qualification on type result with GCC 4.8 only
by Mateusz Loskot 28 Apr '19

28 Apr '19

Hi, (initially posted to https://lists.boost.org/boost-users/2019/04/89778.php) I prepared a lenghty MWE which reproduces my problem with type manipulation using MP11 that for some reason looses const-qualification on a ::type result Here it is at https://godbolt.org/z/eCsakP and copied below. I hope the XXXXXX comments make sense and important static assertions in the main() at the bottom explain what is the expected result. ``` #include <boost/mp11.hpp> #include <cstdint> #include <type_traits> namespace mp11 = boost::mp11; template <typename BitField, int FirstBit, int NumBits, bool IsMutable> struct bit_range_reference { /* long definition, irrelevant */ }; template <typename BitField, typename FirstBit, typename NumBits> struct bit_range_reference_type { using type = bit_range_reference < BitField, FirstBit::value, NumBits::value, true > const; // XXXXXX Why this const gets lost with GCC 4.8 XXXXXX }; template <typename BitField, typename RangeBitSizes> class bit_range_reference_list { template <typename FirstBit, typename NumBits> using reference_type = typename bit_range_reference_type < BitField, FirstBit, NumBits >::type; // XXXXXX Should carry the const, shouldn't? GCC >4.8 do. // If RangeBitSizes is mp11::mp_list_c<int,7,7,2> // then first_bit_list will be mp11::mp_list_c<int,0,7,14,16> using first_bit_list = mp11::mp_fold_q < RangeBitSizes, mp11::mp_list<std::integral_constant<int, 0>>, mp11::mp_bind < mp11::mp_push_back, mp11::_1, mp11::mp_bind < mp11::mp_plus, mp11::mp_bind<mp11::mp_back, mp11::_1>, mp11::_2 > > >; static_assert(mp11::mp_at_c<first_bit_list, 0>::value == 0, "first bit must be 0"); public: using type = mp11::mp_transform < reference_type, mp11::mp_pop_back<first_bit_list>, RangeBitSizes >; }; using reference3_list = typename bit_range_reference_list < std::uint8_t, mp11::mp_list_c<int, 3> >::type; int main() { using r1_t = mp11::mp_at_c<reference3_list, 0>; using r2_t = bit_range_reference<std::uint8_t, 0, 3, true>; using r2c_t= bit_range_reference<std::uint8_t, 0, 3, true> const; //#if defined(__GNUC__) && (__GNUC__ == 4) // GCC 4.8 compiles, later versions of GCC fail to compile static_assert(std::is_same<r1_t, r2_t>::value, "GCC says r1_t is const-qualified"); //#else // GCC 4.9, 5, 6, 7, 8 versions compile, GCC 4.8 fail to compile static_assert(std::is_same<r1_t, r2c_t>::value, "GCC says r1_t is NOT const-qualified"); //#endif } ``` To summary, I expect this to yield true: std::is_same < mp11::mp_at_c<reference3_list, 0> bit_range_reference<std::uint8_t, 0, 3, true> const > I got this confirmed by all GCC versions but GCC 4.8. (clang and MSVC also seem to agree with the GCC >= 4.9) Is mp11::mp_transform loosing const-qualification or have I made a mistake somewhere? I'm using Boost.MP11 from Boost 1.70 and from current develop branch Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 3

[endian] Request for comments
by Peter Dimov 28 Apr '19

28 Apr '19

There are two things that I suspect need to be fixed in Boost.Endian, but the changes are breaking. 1. endian_arithmetic<...> derives publicly from endian_buffer<...>. Intuitively, this inheritance relationship doesn't seem right, and it prevents endian_arithmetic from being a C++03 POD, due to having a base class. 2. the data() member function returns char const*. This type is strongly associated with null-terminated strings, and as such, using it for the underlying bytes of the endian object seems error-prone. I'd much prefer to return `unsigned char const*` from data() (although in C++17 `std::byte const*` might be even better.) I can't however estimate with any certainty whether the (mostly aesthetic) benefit of these changes would outweigh the users' annoyance from their code being broken for no strong reason. Comments?

4 3

CMake, modular Boost, and other stories
by Mike 27 Apr '19

27 Apr '19

Coming at this from a different angle: It might make sense to reserve find_package(Boost_foo) for libraries that directly support installation from cmake. Not sure if such a split is a good idea, but I wanted to put it up for consideration. Best Mike

3 3

PartIcpation in Boost
by Edward Diener 27 Apr '19

27 Apr '19

For personal reasons I will not be able to participate in Boost as I have in the past, which means I will no longer be able to be part of CMT. I will continue to maintain the libraries I created for Boost, tti and VMD, as well as maintaining the preprocessor library created by Paul Mensonides. This means that I will not have the time or the will to be involved with other libraries any more, except on the most general level of discussion. For what it is worth I think that Cromwell Enage should become the maintainer of the Parameter library. I have not, and still do not understand, why when talented C++ programmers are willing to contribute heavily to Boost they are not encouraged and supported more. But this is not my problem. For those who are interested, the experimental C++ standard preprocessor which had been added for VC++ in VS2017 via the '/experimental:preprocessor' switch is still supported in VS2019, although not documented anywhere in the official VS2019 docs. Ths VC++ experimental preprocessor is fully supported in Boost PP and Boost VMD. Unfortunately this preprocessor can not pass all the Boost PP tests, although it has gotten a little better in VS2019 from VS2017. I posted bug reports in Microsoft's bug reporting system regarding its bugs. I have not bothered to test it with the VMD tests, since if it can not pass all the PP tests it is not going to pass the VMD tests. Also while clang on Windows, whether targeting gcc or VC++, passes all the Boost PP tests it fails to pass the VMD tests with lots of errors, seemingly because it is running out of memory ( ? ). I have not bothered reporting this to clang, since my previous experience has shown me that they are clearly not that interested in their Windows implementation. Both gcc on both Linux and Windows, and clang on Linux, pass all the Boost PP and VMD tests. Of course you can try all this out for yourself if you are interested. Edward Diener

3 2

Re: [boost] CMake, modular Boost, and other stories
by Mike 27 Apr '19

27 Apr '19

> +1. Aside from the other benefits mentioned: What benefits exactly? I don't think anyone has mentioned any benefits of dropping the second form at all at all. This isn't an "either or" question - currently both versions are supported. So why exactly should one be dropped? We have talked a lot about Modularization, but little about the original question. Best Mike

1 0

CMake, modular Boost, and other stories
by Peter Dimov 26 Apr '19

26 Apr '19

It's been quiet lately, so it must be time for another CMake discussion. As you know, Boost 1.70 installs CMake configuration files on `b2 install`, and we've started to receive feedback, some of which more interesting than what doesn't work. At present, `b2 install --with-filesystem` for example installs a configuration file boost_filesystem-config.cmake, which enables CMake users to issue the command `find_package(boost_filesystem)` and then use Boost.Filesystem. This mimics what an ordinary, independent library that happened to be called "boost_filesystem" would do. It also installs an umbrella BoostConfig.cmake file, which enables the alternative use of `find_package(Boost COMPONENTS filesystem)`, which treats Filesystem as a component of the package Boost, rather than as a standalone library. This is compatible with the existing, pre-1.70 use of FindBoost.cmake to locate Boost from CMake. Brad King (from Kitware, who should know) argues that installing separate configuration files for all the libraries is wrong. He says that the preferred practice is to only support the second use, with Boost as the package, and the libraries as components, not accessible as packages on their own. (The discussion is here: https://gitlab.kitware.com/cmake/cmake/issues/19186) The reason I went with installing separate configuration files was that I expected that (a) this would be our preferred future approach when, or if, we switch to building with CMake and (b) even if not, this seemed like a step in the right, "modular", direction where libraries are treated as independent rather than parts of the monolithic package Boost. I'm having second thoughts though. It looks to me that Brad is right, and that the various library configuration files should be implementation details of a single Boost package (in the CMake sense) and not be user-visible. That is, only support find_package(Boost COMPONENTS filesystem) and drop find_package(boost_filesystem) Thoughts?

7 11

[build] b2 help moving disjoint_sets
by James E. King III 26 Apr '19

26 Apr '19

I have merged disjoint_sets into boostorg/graph locally and submitted a pull request for it (https://github.com/boostorg/graph/pull/169) The build jobs are failing however, due to disjoint_sets already existing and already having links: https://ci.appveyor.com/project/jzmaddock/graph/builds/24131163/job/uguk1li… b2 headers 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 libs\graph\include\boost\pending\detail\disjoint_sets.hpp. error: Link previously defined to another file, libs\disjoint_sets\include\boost\pending\detail\disjoint_sets.hpp. Command exited with code 1 This happened for me locally when I did the work, so I removed it from the superproject locally, and deleted disjoint_sets locally. Any thoughts on how I can tell the build to ignore disjoint_sets so it can install the headers from the new location and complete? This is a temporary situation until the superproject is updated, but the superproject cannot be updated until the code is merged into graph, and the builds are all failing so I cannot prove to the graph maintainers that the pull request is viable. The only way I can see around this is to rename the disjoint_sets headers from pending and into graph, and then fix up graph and graph_parallel, but my intention was to just merge the header into graph, not to change the location of delivered headers. That said, getting something out of pending is always a good thing. Any other ideas? Thanks, Jim

2 1

Making two Boost libraries interoperate
by Andrzej Krzemienski 26 Apr '19

26 Apr '19

Hi Everyone, Somewhat in connection with the discussion about modularizing Boost libraries, we had a certain conceptual problem recently about providing a customization code that allows Boost.Serialization library to serialize Boost.Optional. Such customization requires some code to be written (template specializations provided). Conceptually, such customization code does not belong to Boost.Serialization: we do not expect that Boost.Serialization provides specializations for every library that someone might ever want to serialize. It would also require the maintainer of Serialization to keep track of the implementation of Optional. However, it also does not belong to Boost.Optional: we do not expect that Boost.Optional provides customization points for every framework out there that the users may want to ever use. It would also require the maintainer of Optional to keep track of the implementation of Serialization. However, it is a natural expectation of a Boost user that if the library offers two components they should just smoothly inter-operate with one another. We could provide a small module Serialization-Optional-interop, but that would require many such components to exist and be maintained by someone. I would like to obtain some guidance on how to address such issue. The same problem must already be present between other Boost libraries. Maybe this has been already brought up, and we have a policy for solving this problem somewhere? Regards, &rzej;

10 23

Google Summer of Code slots
by David Bellot 24 Apr '19

24 Apr '19

Dear Boost community, Google has allocated 11 slots for our summer students this year. It's a great news. It means that 11 brilliant students will have the opportunity to work full-time with us and contribute to our libraries. The selected students will be announced soon. I'd like to thank all the mentors for their hard work in preparing the proposals and helping the students to candidate. And of course, a big thank you to Google for supporting open source every year. Best regards, David Bellot

1 0

undefined behavior in Boost.Program_Options
by Chris Rorvick 24 Apr '19

24 Apr '19

I am seeing my GCC ubsan builds littered with "downcast of address xxxxxxxx which does not point to an object of type 'holder'" errors [3] coming from Boost.Program_options (Boost 1.69). The issue has been documented in various places [1][2] but I do not see anything on the mailing list in recent months; apologies if I have missed something. A workaround is proposed on the StackOverflow post [1]. Does anyone have any thoughts on this? Many thanks! Chris [1] https://stackoverflow.com/questions/38987728/why-does-boostany-exhibit-unde… [2] https://github.com/boostorg/program_options/issues/76 [3] .../boost/boost/any.hpp:249:17: runtime error: downcast of address 0x602000053610 which does not point to an object of type 'holder' 0x602000053610: note: object is of type 'boost::any::holder<std::string>' 6f 00 80 67 d0 91 ec 88 fe 7f 00 00 68 33 09 00 40 60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ^~~~~~~~~~~~~~~~~~~~~~~ vptr for 'boost::any::holder<std::string>' #0 0x7ffe8df13e3d in boost::program_options::typed_value<std::vector<std::string, std::allocator<std::string> >, char>::xparse(boost::any&, std::vector<std::string, std::allocator<std::string> > const&) const (redacted+0x28be3d) #1 0x7ffe88bb0cd5 in boost::program_options::value_semantic_codecvt_helper<char>::parse(boost::any&, std::vector<std::string, std::allocator<std::string> > const&, bool) const (.../libboost_program_options.so.1.69.0+0xdacd5) #2 0x7ffe88ba9193 in boost::program_options::store(boost::program_options::basic_parsed_options<char> const&, boost::program_options::variables_map&, bool) (.../libboost_program_options.so.1.69.0+0xd3193) #3 0x7fff0b727dbf in rdx::launch::OptionsWrapper<boost::program_options::options_description, boost::program_options::variables_map>::prepare(int, char**, std::vector<int (*)(boost::program_options::options_description&), std::allocator<int (*)(boost::program_options::options_description&)> > const&) (redacted+0x448dbf) #4 0x7fff0b755e80 in int generic_wrapper<std::vector<int (*)(boost::program_options::options_description&), std::allocator<int (*)(boost::program_options::options_description&)> >, rdx::Function<int (boost::program_options::variables_map const&), 56u>, rdx::launch::OptionsWrapper<boost::program_options::options_description, boost::program_options::variables_map> >(int, char**, std::vector<int (*)(boost::program_options::options_description&), std::allocator<int (*)(boost::program_options::options_description&)> > const&, rdx::Function<int (boost::program_options::variables_map const&), 56u> const&, rdx::launch::OptionsWrapper<boost::program_options::options_description, boost::program_options::variables_map>&) (redacted+0x476e80) #5 0x7fff0b76593c in redacted(std::string const&, int, char**, std::vector<int (*)(boost::program_options::options_description&), std::allocator<int (*)(boost::program_options::options_description&)> > const&, rdx::Function<int (boost::program_options::variables_map const&), 56u> const&) (redacted+0x48693c) #6 0x95c21d in main (redacted+0x95c21d) #7 0x7ffe82fb83d4 in __libc_start_main (/lib64/libc.so.6+0x223d4) #8 0x963523 (redacted+0x963523)

3 2

Re: [boost] CMake, modular Boost, and other stories
by Mike 24 Apr '19

24 Apr '19

> Hmmm - so no boost library should include any > other boost library? DoesÂ that seem a good idea? Please don't put words in my mouth. I didn't say that and you know it. But the dependency graph could easily be significantly simplified once c++03 is no longer a concern. Again: I'm talking about the future, not the current state. Just an example: [1]Boost.TypeErasure depends on [2]Boost.Thread(and all that entails), just because somewhere in its bowels it needs a mutex. > It's always been good practice to notÂ repeat/copy > functionality in one library into another. Not always. A recent example I stumbled over: Boost.Signal2 depended on boost multi index (which itself depends on a lot of other libs) because it reused it's scope guard implementation (IIRC about 50 lines of straight forward code). Tying yourself to another library for something trivial like that should not be a no-brainer. > But what is really needed - and it may already exist > in BCP but hasn'tÂ been promoted is a simple tool: > a) start with one's application > b) run the app through a tool which recurrsively > reads headers > c) and creates a list of all headers needed > d) extract library names from that list > e) add the git repo of those libraries to my apps > project. So boost should not only get its unique build system, but also its unique dependency management tool? I can tell you as a user: Thanks but no thanks. Also: Didn't you forget source files somewhere in there? What about tests? Bottom line: If boost as a whole was developed as a single project with some coordinated devlopment goal and strategy , it would make sense to distribute it as a single package/framework and a single cmake config file. It seems to me however, that it is more a (huge) collection of independently developed libraries, so I think it is more appropriate to treat them as such, even if there is a huge amount of coupling between them. Am 23.04.19, 23:56, Robert Ramey via Boost <boost(a)lists.boost.org> schrieb: On 4/23/19 2:28 PM, Mike via Boost wrote: > I for one very much hope that boost (at least the libraries that > are actively maintained) will become less coupled > in the future, such that when I just want to use > library X, the rest of boost doesnʼt come as a > dependency with it. Hmmm - so no boost library should include any other boost library? Does that seem a good idea? Itʼs always been good practice to not repeat/copy functionality in one library into another. Iʼve said it many times before so I wonʼt make a big deal about it here. But what is really needed - and it may already exist in BCP but hasnʼt been promoted is a simple tool: a) start with oneʼs application b) run the app through a tool which recurrsively reads headers c) and creates a list of all headers needed d) extract library names from that list e) add the git repo of those libraries to my apps project. I donʼt seen any way to get around this. And util we can easily do this - boost will not be modular. Robert Ramey _______________________________________________ Unsubscribe & other changes: [3]http://lists.boost.org/mailman/listinfo.cgi/boost References 1. http://Boost.TypeErasure/ 2. http://Boost.Thread/ 3. http://lists.boost.org/mailman/listinfo.cgi/boost

6 5

[doc][geometry][gil][signals] Broken links for Boost 1.70
by Mateusz Loskot 24 Apr '19

24 Apr '19

Hi, 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/geometry/index/doc/html/index.ht… https://www.boost.org/doc/libs/1_70_0/libs/geometry/extensions/doc/html/ind… https://www.boost.org/doc/libs/1_70_0/libs/gil/doc/html/index.html 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? p.s. I considered posting to boost-docs but that list seems inactive. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

5 5

CMake, modular Boost, and other stories
by Mike 23 Apr '19

23 Apr '19

I'm very much in favor of separate packages. James is right, that - at the moment - most boost libraries are so tightly coupled that they can't really be treated as separate libraries, but when changing things it is just as important to ask, "Where do you want to go?" as "where you are now". I for one very much hope that boost (at least the libraries that are actively maintained) will become less coupled in the future, such that when I just want to use library X, the rest of boost doesn't come as a dependency with it. It also fits the management structure (or rather the lack thereof) much better. Also, the mechanisms for modular boost distributons already exist through e.g. vcpkg and conan, so I don't see the problem in also providing independent cmake configfiles. Finally: About how many libraries are we talking here anyway? Only the compiled ones get their separate config file - correct? Best Mike

3 2

[GSOC2019][Boost.uBLAS]
by swornim baral 23 Apr '19

23 Apr '19

Hi List, I realize the deadline has passed for seeking a mentor for GSOC, and I apologize for the delay in initiation. I came to know about the program two weeks prior to the deadline, and started working on completing my proposal and competency test prior to finding any mentors. However, I am still very much interested in working on the project of adding a new numerical and multi-linear algebra algorithm to Boost.uBLAS library. I would love to work on the algorithm for calculating Kronecker and Hadamard product with the guidance of a potential mentor. Since I submitted the proposal in a hurry and without any discussion with a mentor, I could not include specific implementation details in my proposal. Below is the link to my final proposal that I submitted for the GSOC 2019. I would really appreciate any feedback on the proposal, competency test and suggested reading materials to get a head start on implementing the algorithm from any interested mentors. https://drive.google.com/open?id=1saUedBfMCOpmVqQfn1a3YcfPtjPYLeDC . Sincerely, Swornim baral

1 0

Re: [boost] CMake, modular Boost, and other stories
by Peter Dimov 23 Apr '19

23 Apr '19

> Mike wrote: > > > Finally: About how many libraries are we talking here anyway? Only the > > compiled ones get their separate config file - correct? > > ~30-40 at last count. Yes, at the moment. More like 50. Some libraries install more than one.

1 0

[variant2] Formal review
by Bjorn Reese 20 Apr '19

20 Apr '19

I. DESIGN --------- The main design decision of Variant2 is the never-empty guarantee, which is relevant when replacing the value of a variant. This is done without overhead if the alternative types are "well-behaving"; if they are not, then Variant2 falls back to using double storage. This is a major difference to: * std::variant which enters an invalid (valuless_by_exception) state. While that may be appropriate for some use cases, there are others where it is not. For instance, the variant may be used for a state machine where the alternative types are function object types to be invoked when events arrive. Having a valueless state is the wrong choice for this use case. * Boost.Variant which uses a temporary heap object instead. Avoiding this internal heap allocation is sufficient grounds for another never-empty variant type. In time critical applications heap allocation not only introduces indeterministic timing, but may also incur priority inversion due to thread synchronization within the heap allocator. Variant2 has several ways to ensure the never-empty guarantee: V1. If all alternative types have non-throwing assignment, the variant cannot fail during re-assignment. V2. If an explicit null state is available, then this is chosen on re-assignment error. This is similar to std::variant, except is is opt-in. V3. If one of the alternative types has a non-throwing default constructor, then this is chosen on re-assignment failure. V4. Otherwise, the variant will remain it its old state (due to double storage) if re-assignment fails. Criterion V3 is possibly surprising because the variant may change to another type not anticipated by the user. This should be opt-in instead (e.g. using a tag.) I am missing a function to get the index of a type to work with the index() function. Something similar to holds_alternative() but that returns the index instead of a boolean. This useful in switch statements, when we want to avoid visitors for some reason: variant<int, float> var = 1; switch (var.index()) { case index_of<int>(var): /* Do int stuff */ break; case index_of<float>(var): /* Do float stuff */ break; } It would also be beneficial for performance reasons to add accessors that have a narrow-contract, similar to relaxed_get() in Boost.Variant. The implementation is already there (detail::unsafe_get.) Better compiler error messages would be desirable. For instance, if we use an illegal visitor that has different return types, then the compiler error does not give us any hint about the different return types. II. IMPLEMENTATION ------------------ The implementation is high quality. Although it does lots of meta-programming, most of the style is simple and easy to follow, especially if you have a rudimentary knowledge of Boost.Mp11. In a few places, like the visit() return type, the meta-programming is more hardcore. variant<T...> defines _get_impl as a public "private" function. This can be made more safe by using detail::unsafe_get instead of _get_impl throughout the code. detail::unsafe_get will continue to call _get_impl, but the former should be made a friend of variant<T...> such that _get_impl can be made private. The other public "private" function, variant<T...>::_real_index(), does not seem to be used and can be removed. The emplace_impl(mp_false, mp_false, ...) contains two distinct cases that depend on a compile time condition. If this is split in two, then the two assert()s can be changed into static_assert()s. The variant_alternative and get functions have a couple of compiler workarounds. The code could be made clearer if the workaround is always used for all compilers. Or does is this related to C++11 constexpr? III. DOCUMENTATION ------------------ The documentation is mainly aimed at experienced users. There is no tutorial for people unfamiliar with variant types, nor is there a design rationale that explains why Variant2 is exists when we already have Boost.Variant and std::variant. The reference documentation is adequate, although a bit terse. IV. MISC -------- Having written my own variant class (that has a maximum size, and any type exceeding the limit is allocated on heap) puts me in a good position to assess Variant2. I was also the review manager of Boost.Mp11 upon which Variant2 is built. I have spent 5-6 hours reading documentation, reviewing the code, and writing small test programs. V. VERDICT ---------- Variant2 fills a hole not covered by Boost.Variant and std::variant. I vote to CONDITIONALLY ACCEPT Variant2 into Boost, provided that the following change be made: 1. The selection of an arbitrary non-throwing type in case of an re-assignment failure (criterion V3 in the DESIGN section above) should be made optional. By default it should use double storage in this case. I would furthermore like to see improvements to the documentation, as well as the index_of/safe_get functionality, but neither is a requirement for acceptance. I have not reviewed expected<T, E...>.

11 29

[boost-ci] Build failures for repositories using boost-ci
by James E. King III 19 Apr '19

19 Apr '19

Recent changes to boost have exposed some shortcomings in the boost-ci infrastructure, specifically the use of CXXFLAGS as a variable to hold b2-specific "cxxflags=" content is now getting passed through to the bootstrap build and going to the compiler, and failing. I'm aware of the issue and I am working on a fix that will be backwards compatible with existing Travis CI scripts that use boost-ci to drive their builds. There may also be changes for Windows, but I haven't looked at that yet. This affects the majority of the CMT repositories as well as date_time, format, uuid, function, move, and signals2, and possibly others. More information to follow... - Jim

1 1

[serialization] clarify in doc on overview that library does not aim for inter-process communication nor for backward compatibility
by rafalcpp＠peerfreedom.org 18 Apr '19

18 Apr '19

Hello, Some developers expect archiving or serializing libraries to be backward compatible, for example if I simply save vector<string> to a JSON, then files written from program with more modern json library will be readable on older one and vice-versa. Boost serialization is instead rather intended to read files created by same program with same boost version (or read it on a more recent, but not on older, version of boost). Could we clarify this with a warning on the Overview page? Perhaps something along this lines: " Warning: please note that the format version may change with boost.archive library versions, an old program may not be able to read a format that was designed after it was build. Explanation: some archive libraries offer long lasting forward and backward compatibility of the archived data. For example if your program saves list of book titles into a JSON file, then if your main program itself does not change you can expect to always be able to load that json file - even when loading it on old version of JSON library while archive was saved on a very new one. This is however *not* the case for this boost archive library (at least for the default archive classes) - here even if your main program stays the same then archives written on one using more recent libboost might be unreadable on ones using older libboost. This also means that communication between users (e.g. over Internet) by exchanging archives created by this library will not work in case if users build the program on their own and build it against different versions of boost. Although, a work around exists in form of including specific version of boost serialization library, and freezing that version, in your program, if you are willing to stick to one version of this module. " Please correct if there are any mistakes (for example if that is possible in some special way).

2 1

[variant2] Review
by Jan Herrmann 17 Apr '19

17 Apr '19

Hello, I looked at the review, at the code and some time ago I tried to implement my own variant. In my opinion in variant2 the individual parts are more worth than the whole. Most implementation details would be of great use for implementing variants with a differnt trade-off. Hence the library ought to be split into several independend parts: * a typing switch * a variadic union * an extendable visitation mechanism * a variant view * related type traits * several implementation of a concrete variant 1. A typing switch The typing switch would be provide a litle bit more than (and can be implementated with help of) mp_with_index. The following pseudo code shows the implementation idea: template<size_t MaxIndex, class Function, class Cast, class Object> constexpr decltype(auto) typing_switch(size_t index, Function fun, Cast cast, Object obj) { return fun(cast(integral_constant<size_t, index>{}, obj)); } The object is a variant and the cast transfroms this special variant to a concrete value (with type). The function is provided by the variant user. The visit function (line 1732) would become something like this: template<class Variant> struct variant_cast { template<class Index> constexpr decltype (auto) operator()(Index, Variant& V) { return unsafe_get<Index::value, V>(); } }; template<class Fun, class Variant> constexpr decltype(auto) visit( F&& f, V1&& v1 ) { return typing_switch<variant_size<V1>>(v.index(), f, variant_cast<V1>, v1); } A simplified deserialisation can be implementated as follows: template<class Types> struct index_to_type { template<class Index> constexpr decltype (auto) operator()(Index, std::nullptr_t) { return mp_identity<mp_at<Types, Index>>{}; } }; template<class Variant, class Archive> Variant deserialize(Archive& ar) { size_t index; ar >> index; Variant f = [&ar](auto type) { decltype(type)::type concrete_element; ar >> concrete_element; return Variant{std::move(concrete_element)}; }; return typing_switch(index, f, index_to_type<Variant>{}, nullptr); } With help of this function an implementation of a visitation function is easy. 2. A varidic union Without doubt a type implementing a varidaic union is a building block for almost every variant implementation. It should be part of the public interface, well tested and with a minimal interface (get<i> and emplace<i>) 3. An extendable visitation mechanism This could be used to implement visitation on multiple different variants. It should use visit on one variant as customization point. 4. A variant view (and a mutable variant view) It could have the following form: template<class... T> class variant_view { void* value; size_t index; public: /* visit ... */ }; It is a little bit like folly/DiscriminatedPtr.h (https://github.com/facebook/folly/blob/master/folly/DiscriminatedPtr.h) but without platform specific code. It can be used for functions which take variants as a const references (or in the mutable form as variants which can change the value but not the actual type). It can be constructed from corresponding variants, values (which are part of T...) and other variant_views. As long as it is constructed from a variant implemented with the variadic union the process can be simple: all members of a union have the same address as the union and the index is equal. For special cases the process can be more complicated. For other variant_views the transformation can be implemented as a runtime lookup in an array and for simple values it is simple. A variant_view can for example be used for functions accepting const references like output and serialisation, or for referencing "polymorphic" objects like nodes in ASTs. 5. Related type traits Meaningfull type traits which can be used in one variant have a good chance be be used in a related one. If one variant want to static assert in case void is one of its types the logic is probably usefull for others. They should be collected. 6. Several implementation of a concrete variant This is the place for variant2. With this building blocks it should be simpler to implement a custom variant. Now lets think of a few use cases: A class contains 3 variants each containing only a few "small" types. Instead of using 3 variants it could pack all indices into one int and construct variant_views as needed. This can reduce the size of the class and saves memory bandwidth. Editing of variants would be of course more complicated. A variant containing a few trivial small types which are used in allmost all cases and one type (T_evil) which is used rarely, is big and can throw in certain situation. The soloution can be a normal variant with the exception of storing T_evil as a smart pointer and dereferences it when visited. A variant with allocator support. In case a user has a solution (or idea) for their variant which lives in shared memory a simple blueprint with generic components like varidic union, a typing switch and useable type traits may be of help. I think requirements for different variant types mentioned in the review could be implemented with some well defined basic building blocks. Beside these thougths I looked at the library. expected.hpp: I tried to compile the following file (containing only one non empty line): #include <boost/variant2/expected.hpp> and it does not compile. It should be a self-contained header. Therefore it should be not part of the library. variant.hpp: Personally (in contrast to other reviewers) I would prefer code more structured in different files. In an ideal world there is for every component a single header file (in clean C++ 17) with minimal dependencies which directes for compiler (and version) specific stuff to a different header. For the future it would result in source code written in newest standard without disturbing influence from ifdefs caused by old buggy compilers. The source has more than 1800 lines with only a few comments, short (1 char) names and very long lines (200 chars and more). For me it is not easy to read (after clang-format it is 2030 lines). Variant alone has more than 450 lines of code. With more shorter files the connection of (and dependencies among) the components would be more visble. I started at the begining of the file and searched for a testcases for monostate and I didn't found one. There are a few testcases inside variant_valueless.cpp which use monostate but none which test it directly. Next variant_size. There are testcases but most deal with variants of type 'variant<> const', 'variant<void>' and the like. Declaring variables of these types results in compile time errors. It is not wrong std::variant gave me the same result, but it is a kind of strange that most tests are implemented in terms of variants wich are ill-formed. On the other hand there are no tests which do not compile. These are two example which should not compile. The template detail::variant_alternative_impl looks like something which copies const, volatile and references. Is there a difference to copy_cv_ref at the end? Could it be used? At the end of the file the comparison is implemented. But operator!= is not implementated in terms of operator== and operator<= and others not in terms of operator<. In case there is a reason for it documentation would be nice. Summarized I think variant2 should NOT be part of boost. I think the focus should be more on reusable components and better documented code. I think most of the code could be very usefull with more descriptive names and test. Regards Jan Herrmann

7 10

[variant2] Review of Variant2 started today : April 1 - April 10
by Michael Caisse 16 Apr '19

16 Apr '19

The Boost formal review of Peter Dimov's Variant2 library will take place April 1 - 10, 2019. Please consider participating in this review. The success of Boost is partially a result of the quality review process which is conducted by the community. You are part of the Boost community. I will be grateful to receive a review based on whatever level of effort or time you can devote. Variant2 is a never-valueless C++11/14/17 implementation of std::variant. >From the README: The class boost::variant2::variant<T...> is an almost conforming implementation of std::variant with the following differences: * A converting constructor from, e.g. variant<int, float> to variant<float, double, int> is provided as an extension; * The reverse operation, going from variant<float, double, int> to variant<int, float> is provided as the member function subset<U...>. (This operation can throw if the current state of the variant cannot be represented.) * variant<T...> is not trivial when all contained types are trivial. To avoid going into a valueless-by-exception state, this implementation falls back to using double storage unless * one of the alternatives is the type monostate, * one of the alternatives has a nonthrowing default constructor, or * all the contained types are nothrow move constructible. If the first two bullets don't hold, but the third does, the variant uses single storage, but emplace constructs a temporary and moves it into place if the construction of the object can throw. In case this is undesirable, one can force emplace into always constructing in- place by adding monostate as one of the alternatives. You can find the source code here: <https://github.com/pdimov/variant2> The master branch will be stable for the review: <https://github.com/pdimov/variant2/tree/master> Find the documentation here (also stable during the review): <https://pdimov.github.io/variant2/doc/html/variant2.html> Note: The repository contains an expected implementation also; however, that is not being considered in this review. Please provide in your review information you think is valuable to understand your choice to ACCEPT or REJECT including Variant2 as a Boost library. Please be explicit about your decision (ACCEPT or REJECT). Some other questions you might want to consider answering: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With which compiler(s)? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? More information about the Boost Formal Review Process can be found here: <http://www.boost.org/community/reviews.html> Thank you for your effort in the Boost community. Happy coding - michael -- Michael Caisse Ciere Consulting ciere.com

8 20

Mother of all Variants
by Nikita Kniazev 16 Apr '19

16 Apr '19

I do not see any progress in the never-ending never-empty vs everything discussion. It looks like an argument about tastes, and I see no room for compromise here. Number of examples for any point of view is also close to zero. Instead of saying that you would like more one or another, just implement it, and let the user decide which one to use. Or, at least, make a poll that will show needs in promoted by you implementation instead of forecasting from your big, but personal experience. A policy-based design is good in theory, but what in practice? In practice, you want one person to make and maintain bunch of different variants, which you, most likely, will never use, but users, most likely, will have nightmares in using it, especially in API, due to signature verbosity. More code will hurt preprocess and compile times for sure. What surprises me a lot that there was not much attention to the fact that because of number 2 in the name users will come and will ask about it. Do I need an upgrade? Is `variant` deprecated? Is `variant2` an improved version of `variant`?

1 0

GSOD
by Siddhartha Sen 16 Apr '19

16 Apr '19

Any information on how and where to apply for GSOD?

2 1

[variant2] Andrzej's review
by Andrzej Krzemienski 16 Apr '19

16 Apr '19

Hi Everyone, I recommend that variant2 should be REJECTED in its current shape. The main (and only) reason for rejection is the never-empty basic exception-safety guarantee offered and endorsed by the library. I have serious concerns that by adding it into Boost we would be leveraging the concept that is bug prone and encouraging bad habits. I have expressed my concerns in detail in another mail. I find this to be in contrast with what I perceive as goals of Boost. It is my understanding that the never-empty basic guarantee is the core of the library therefore the conditional acceptance would not work. My recommendation would be different if the library dropped the goal of providing the never-empty guarantee, or if it provided a strong guarantee in the cases where assignment emplacement required to change the alternative. I honestly appreciate the work Peter has done to provide this library, but I strongly disagree with the primary design decision. If the library is still accepted I recommend the following things: 1. Call it something slightly different so that at least namespace name clearly indicates that it is not an "improved std::variant" or "improved boost::variant" but just another offer in the market with different design choices in the design space: maybe ne_variant (for "Never Empty") or si_variant (for "Strong Invariant"), or even pdimov_variant (for "Perfectly Defined Invariant Model Of Variant"). 2. Drop the implementation of std::expected. It does not fit into the same library even if 90% of the implementaiton is shared. Propose a second library even if what it does is to #include the variant. 3. Move functions unsafe_get() from namespace detail and make them part of the official interface. You need to use them yourself in the implementation of visit() because otherwise you could not implement it efficiently. They are part of the minimum efficient base interface. Even if required very occasionally. 4. Provide a 2 minute introduction to the library for the newbies. We do not need a full tutorial. A link to someone else's description will do, but a short introduction I think is a must. I offer to help write one. 5. Provide a design rationale explaining why the never-guarantee is offered at all and why in this way. Why you are disregarding the design choices of boost::variant's never-empty guarantee. Also provide a detailed description on which algorithm is chosen under what circumstances and what it does to provide the guarantee. Now, to review questions: - What is your evaluation of the design? As noted, I strongly disagree with the main design choice of the library: the never-empty guarantee. I see no positive value, I see negative value. This aside, I do not see much design choices here: it is a quite small vocabulary type. - What is your evaluation of the implementation? Of all reviews I have participated in I have never found it so easy to understand the implementation. I find it very clean and short. I appreciate that it is a single header library. I can just copy the content of the file and test it in WandBox. Also the implementation is a very good practical tutorial on mp11. Peter already wrote good tutorials on mp11, but here for the first time I have seen it used for something that I consider a real life application. The implementation of variant looks so simple with mp11. - What is your evaluation of the documentation? The reference part meets the high standards of Boost. I am missing even a short introduction that would give us the motivating example. Some have said that it is enough to say "find the tutorial on std::variant". I disagree: there is no good introduction to variant, and I think Boost libraries have a good history for providing a good problem domain description apart form the implementation. I also think that given the controversies around the never-empty guarantee the design choice requires a detailed information in the docs. - What is your evaluation of the potential usefulness of the library? Given that I find std::variant design superior, I suspect this library would be useful in environments that cannot afford to use C++17 yet. It has advantages over boost::variant. It has cleaner implementation. boost::variant is giving me lots of warnings in clang-tidy. I expect these to be gone in variant2. Also the trade-offs made in double buffering may be superior to those in boost::variant: no memory allocation, no additional potential reason for throwing. - Did you try to use the library? With which compiler(s)? Did you have any problems? I tried to break the library with nasty cases in various clang and GCC versions. I reported some minor bugs over GitHub. Peter is quickly addressing them. The library does not compile in GCC 8.2 and higher in C++17 mode due to some bug in GCC. This is already tracked as issue. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I have spent a number of evenings reading the docs, the sources, playing with the library, debugging, discussing the design in the mailing list. I also followed the discussion in the C++ Standards Committee, where similar issues with never-empty guarantee were discussed. - Are you knowledgeable about the problem domain? I have a lot of experience with different implementations of `optional`: I am maintaining the boost version, I have provided the wording and the design for the std version and provided the reference implementation thereof (at https://github.com/akrzemi1/Optional/) which turned out surprisingly popular. Optional needs to solve similar problems in the implementation: manually managing a raw buffer or a union, and has similar problems with exception safety guarantees. However it does not need to address the never-empty guarantee issue. I also use a lot of boost::variant at work. Finally, I want to thank Peter for writing this library and submitting it for review. The review itself was very instructive. Regards, &rzej;

10 19

[doc][test] change log broken from release notes
by Raffi Enficiaud 15 Apr '19

15 Apr '19

Hi, The link to the change logs is broken from the 1.70 release note (points to https://www.boost.org/users/history/libs/test/doc/html/boost_test/change_lo… instead of https://www.boost.org/doc/libs/1_70_0/libs/test/doc/html/boost_test/change_… ) I believe I used the same way I did for the past releases. How can I correct this? Thanks, Raffi

1 0

Re: [boost] [boostorg/python] Building against multiple python implementations broken on 1.70 (#262)
by Stefan Seefeld 15 Apr '19

15 Apr '19

On 2019-04-14 7:50 p.m., Peter Dimov wrote: > > I'll need to look into this. Apparently, |FindBoost.cmake| solves this > by forcing the user to specify the version in |find_package(Boost > COMPONENTS python27)|, but the CMake configuration files installed by > 1.70 only take |find_package(Boost COMPONENTS python)|, so multiple > versions installed at the same time are a problem. > > In the meantime, you can add |--no-cmake-config| to your |b2 install| > command line to skip the installation of CMake configuration files, > which ought to give you the 1.69 behavior back. > This is *exactly* the kind of situation I was afraid of when I argued strongly against adding CMake support to my own projects: Before I had to deal with B2 issues that I had difficulties resolving myself. Now I have to deal with B2 *and* CMake issues, being even more dependent on others. That's not my definition of progress. Stefan -- ...ich hab' noch einen Koffer in Berlin...

3 4

[variant2] never-empty guarantee considered harmful
by Andrzej Krzemienski 15 Apr '19

15 Apr '19

Hi Everyone, I waned to re-iterate my concerns regarding the never-empty guarantee provided by variant2 (as well as by boost::variant). Sorry for starting a yet another thread, but I think it necessary to cleanse, group and structure the information scattered among a number of threads. I think that the never-empty variant deceives people into thinking that it offers something useful and important, but in fact it does not, and more, it can encourage people to trust that they have some guarantee which they haven't, and owing to this to write buggy code. The solution that never-empty variant offers is similar to another common idea of replacing undefined behavior with *any *defined behavior whatsoever, and that is supposed to be "safe" because programmers no longer see symptoms of their bugs. Let me digress on the subject of UB for a second. UB is always caused by a bug in the program. Thus if the program had no bugs, it would have no UB. But many people are very afraid of UB per se, and less afraid of bugs. They will divert much attention to prevent UB at surprisingly high cost, but focus less on preventing their bugs. UB is a useful symptom of a bug and therefore can help detect and remove bugs, but people are sometimes so afraid of UB that they loose this connection to the extent that they are willing to remove the link between the two and get rid of potential UB even at the cost of concealing the bugs. And they consider it "safe". For instance, someone writes a sequence container class and faces the problem. I will need to provide access to elements by index, but people will give me bad indexes (because they can), this would be a UB, and I do not want a UB, therefore I apply a "safety" feature. Whenever someone gives me bad index, I will return a reference to the first element. Sure, it is surprising, and likely not what the caller wanted, but it is better than UB. And in case I have no elements in my container I will default-construct one in the container. Sure it is not nice to to increase the size of the container only because someone gave me the wrong index, but... *anything is better than UB.* I wonder if everyone reading this mail will agree with me that reasoning "anything is better than UB" is wrong. The author of this "safe" container calls his container "safe" because whatever bugs his callers have, they will never trigger UB *in his library*. Maybe in another library, at another level, but not in his component. In the end we will get programs that will cause self-driving cars to crash and kill people, space rockets to explode, but the "safe" program itself will never crash. Instead the author of the "safe" container should be focusing on something else. Why is my caller giving me the wrong index given that he can check my size and easily determine that this index is wrong? The answer is, the programmer probably intended to do something else and this needs to be brought to his attention. Tools like compilers and static analyzers cannot detect bugs in general because they cannot guess our intentions, but they can detect things like UB, so if we keep a correspondence between bugs and UB, we can detect bugs by detecting UB. This has been described in more detail in this paper: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1043r0.html (section 6). Now, the situation is similar with the never-empty guarantee of the variant that offers only a basic exception safety guarantee on assignment. Because the guarantee is basic (that is, it is not the strong guarantee), the only thing we can do with it in order not to risk program bugs is, following the Dave's article (https://www.boost.org/community/exception_safety.html) to either destroy or reset the variant that threw from assignment. And this is what correct programs do, and the technique is quite simple: unless objects provide strong exception safety guarantee (or some other guarantee that allows you to reason about the values of objects that threw) they should die in the stack unwinding process. The damage that the never-empty guarantee (implemented by setting unexpected values) does is to encourage people to think that with variant they can do something more than just destroy or reset. And while technically, variant itself is "clean" in this case (it really doesn't invoke UB itself) it causes the code that is using it to be incorrect. Two examples. I may have the following instance: ``` variant2<X, Y, shared_ptr<Z>> v {X{"params"}}; struct Visitor { int operator()(shared_ptr<Z> const& z) { return z->getCount(); } int operator()(X const&) { return 1; } int operator()(Y const&) { return 1; } }; ``` Where X and Y have nasty properties (are declared to potentially throw from move constructor and do not have default constructors). My v could technically store a null pointer at some point. In the visitor I do not check for this eventuality. Someone could say, "you should always check for null pointer, because anything is better than UB", But I know I never will be storing a null pointer there. I use shared_ptr for its ability to share ownership of an object, not for its ability to be null. I guarantee that I will never set the shared_ptr<Z> alternative to nullptr value. Therefore in the visitor I can assume that the pointer is never null. But if I am encouraged by the variant's never-empty guarantee to depart from Dave's guidance not to trust basic-guarantee objects that threw, I may end up in the situation where I start with alternative X, I want to assign alternative Y, but it throws, and because the only type with the default constructor is shared_ptr<Z>, I will get a nullptr value which I never intended. This is not bad yet. But now, if I apply my visitor on my variant, my precondition that the pointer is not null will be violated: ``` variant2<X, Y, shared_ptr<Z>> v {X{"params"}}; BOOST_SCOPE_GUARD(&v) { visit(Visitor{}, v); }; v.emplace<Y>("params"); // throws ``` Now, variant2 fulfills its guarantee: it stores one of the alternatives (of arbitrary choice and arbitrary value), but it injected me the worst possible value of the type with the weak invariant. Thus, variant2's invariant may be strong, but it exploits the weak invariants of the types of the alternatives. And unfortunately, a lot of types, even in the STD, have weak invariants and use the default constructor to set the degenerate state. Thus, my program has UB, and hopefully a crash, because I was deceived by the never-empty guarantee: I thought it would be "safe" to observe such variant that threw. Second example comes from Peter: ``` template<class T> class monitor { T const& v_; T old_; public: explicit monitor(T const& v) : v_(v), old_(v) {} ~monitor() { if( v_ != old_ ) std::clog << "value changed"; } }; ``` Suppose I use it like this: ``` { variant2<X, Y, shared_ptr<Z>> v {shared_ptr<Z>{}}; // let me check if this code sets the v to a non-degenerate value: monitor m {v}; v.emplace<X>("params"); // succeeds v.emplace<Y>("param"); // fails: null pointer set. } // no value change reported ``` although the only state changes I initiated in this block were to set types X and Y, I got the wrong result from the monitor, because the "safe" guarantee of the variant chose some state that corrupted the monitoring logic. variant2 delivers its guarantee as promised: some value is there, but my monitoring is compromised because of its arbitrary choice of value. Note that std::variant does not have this problem: a distinct state is set upon such exception that is always different than any value of any of the alternatives. Of course, this second example has problems of its own. It assumes you can invoke operator== on an arbitrary T of which we know nothing. It assumes that T's invariant allows the values to be compared, but this is not correct an assumption. Type T can have a weak invariant: one that does not even allow comparing two values. You cannot just invoke arbitrary operations on an unknown T in the destructor, if you do not know they exception safety guarantees. T's comparison could potentially throw. Even destructors of generic components such as vector<T> or optional<T> in their non-trivial implementations only invoke operations on concrete types: pointers and bools, but for the T they only call destructors. Peter argues that a call to the operation on a variant could be invoked indirectly form the destructor: destructor calls function f(), function f calls function g(), function g() calls function f() and function h() makes a visitation on the variant. But can you see what this means? I am calling some function f() from the destructor, which is supposed to clean up resources, and I am not sure what f() does, if it does some hidden things beyond my control. This is a buggy code already. Now, to address another argument in favor of never-empty, arbitrary-value-choosing guarantee. Emil says that with never empty-guarantee we can more easily reason about the variant: it is *always* one of the alternatives: rather that "either one of the alternatives or some degenerate state. He argues that once we allow the faintest possibility for the degenerate state, we have to check for it *everywhere*. I think that the simple binary model, "either the weak state does not exist or is potentially everywhere", while it often works for many types is, not adequate to describe the reality of the variant. People need models (which are simplifications of reality) to help them manage complex reality. But models have the downside of not allowing people to see the reality beyond what the models allows them to see. We ave to distinguish "ordinary" weak state and "unusual circumstance" weak state. Types like unique_ptr or fstream have ordinary weak state: it is created by a constructor. Worse, by the default constructor, so if you just declare the variable name and forget about parameters you immediately get the weak state. It is easy to obtain this state. And therefore in many places we need to be prepare to handle them. But other types (which we have fewer in STD: only std::variant, I think) can have only "unusual circumstance" weak state: you cannot initialize the object to contain this state (unless you move/copy construct from another object that already has one). You can only get it in situations that for other reasons require special caution from programmers. I am aware of two: * when an object is manually moved from (by explicitly casting an lvalue to an rvalue reference, which std::move() does) * when a mutable operation on an object with basic exception safety guarantee threw an exception. In the first situation, in a generic context where we work with an unknown type T, after the move an object is in a valid but unspecified state. Type T is allowed to have a very weak invariant: so weak that even operator== may not be allowed to be invoked. In this state the only correct thing we can do is to either let the object die or reset its value (the only common way for resetting the value for different types is assignment of a non-degenerate value). Working under the assumption that programmers are aware of these constraints and are willing to adhere to them, we get confidence that these moved-from values will not be observed. (Of course this does not apply to types which choose to guarantee more after move.) We can design a resource-handling type, such as a socket, whose default constructor acquires the first available port, and leaves the object in a "strong" state, ready to work. there is no way to initialize objects of this type to a degenerate value. but if these sockets are move-constructible, the moved from object will have to store the degenerate value. But it would be pointless to check it anywhere in the program. We could only see it if programmers did not adhere to the rule, "only assign to or destroy the moved from objects, unless you know your object offers more guarantees". If programmers do not adhere to this rule, rather than covering up for their bugs, socket should make the UB as explicit as possible in order to assist static analyzers and tools in detecting such programmer's misuse of the moved-from state. Similarly with the after-throw state from the basic guarantee operation. The language cannot enforce this, but programmers are required to adhere to the rule: the only correct operations to be invoked in that case is to destroy the object or to reset it. again, if programmers do other things this is a bug and the type should try to reflect that in a controlled UB, rather than pretending that everything is fine and causing bugs later in unpredictable places, as was shown in the examples above. Insisting that unusual-circumstance weak state should be checked *everywhere* is depriving oneself of the ability to see the engineering trade-offs clearly. We do not have to distinguish "ordinary" and "unusual-circumstance" weak states in most of other types (nearly all types) because they do not pose so many implementation difficulties as variant does: implementing never empty guarantee costs too much in terms of run-time or spatial efficiency. For the sake of the simplicity of the model we cannot sacrifice too much efficiency. Given that efficient implementation of variant does not fit into the simple model, "either I have a strong invariant or not", one option is to provide a misleading and/or never-empty guarantee. But another option is to acknowledge that the simple model is no longer sufficient, and adapt a new one: more complex but one that better reflects the reality: we have two invariants: one that applies in normal code (where every function can be freely called and a weaker one that applies in circumstances that already require special caution from programmers. This is the C++ way: we deal with UB which some other languages do not have at all:this is more complex a task but allows for faster binaries and better bug detection. In a similar vein paper "Fixing Relations" ( http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1248r0.html) has been recently adopted in the C++ Standards Committee. The proposal compromised a nice and simple mathematical model, but this part of the model stood in a way to use some STL algorithms efficiently. C++ is not an easy language, and by trying to make it appear simpler than it is, we might only confuse the new programmers. One more thing, it is not the surprising value that variant2 may set upon the exception that bothers me the most. It is rather that indirectly it encourages programmers to think that it is fine or "safe" to read the value of the object that has been moved from or that threw from the basic-guarantee operation. We do not want to suggest that. Finally, all the above reasoning would not apply if variant offered a strong guarantee on assignment/emplacement for cases where the alternative needs to be changed. In that case: 1. It is perfectly fine to observe the state of the object that threw. 2. No surprising, potentially weak-state, value is ever fabricated in this case. Regards, &rzej;

4 5

update of release notes for boost-1.70.0
by Oliver Kowalke 15 Apr '19

15 Apr '19

Hi, I've added 3 pull requests for boost/website... could you apply the patches and re-create the release notes for boost-1.70.0, please?! ty, Oliver

1 0

Re: [boost] [boostorg/python] Building against multiple python implementations broken on 1.70 (#262)
by Stefan Seefeld 15 Apr '19

15 Apr '19

On 2019-04-14 7:50 p.m., Peter Dimov wrote: > > I'll need to look into this. Apparently, |FindBoost.cmake| solves this > by forcing the user to specify the version in |find_package(Boost > COMPONENTS python27)|, but the CMake configuration files installed by > 1.70 only take |find_package(Boost COMPONENTS python)|, so multiple > versions installed at the same time are a problem. > > In the meantime, you can add |--no-cmake-config| to your |b2 install| > command line to skip the installation of CMake configuration files, > which ought to give you the 1.69 behavior back. > This is *exactly* the kind of situation I was afraid of when I argued strongly against adding CMake support to my own projects: Before I had to deal with B2 issues that I had difficulties resolving myself. Now I have to deal with B2 *and* CMake issues, being even more dependent on others. That's not my definition of progress. Stefan -- ...ich hab' noch einen Koffer in Berlin...

1 0