August 2019 - Boost - lists.preview.boost.org

A solution to return dynamic strings without heap allocation. Any interest?
by Roberto Hinz 09 Oct '19

09 Oct '19

Hi all, I haven't been succesful at attracting interest in a formatting library [1] I've been working lately. But recently I realized that part of it could be isolated as a small standalone library that could solve an old common troublesome situation in C++: Suppose you need to create a function that returns/provides a string whose content and size is unknown at compilation time. The first approach is to make it return a `std::string`. But if it need to be usable in environments like bare-metal real-time system, then one usually makes it take a raw string as an output argument, more or less like this: struct result{ char* it; bool truncated; }; result get_message(char* dest, std::size_t dest_len); But this is clearly not a perfect solution since there's nothing really effective the caller can do when get_mesage fails because of the destination string being is too small. So I present the `outbut` abstract class. It somehow resembles `std::streambuf`, but with a simpler and lower level design, which is the result of many attempts looking for the best performance [2] and usability in my formatting library. Afaics, it does not require a hosted C++ implementation, though I would like someone else to confirm that. Now the caller of `get_message` has to choose or create a suitable class type deriving from outbuf, that dictates where the message is written to. For example, if the user wants to get a `std::string`, then `string_maker` will do the job: #include <boost/outbuf/string.hpp> // ... boost::outbuf::string_maker<false> msg; get_message(msg) std::string str = msg.finish(); Or, if one wants it to write into a raw string, then use `cstr_writer` char buff[buff_size]; boost::outbuf::cstr_writer csw(buff, buff_size); get_message(csw); auto result = csw.finish(); if (result.truncated) { // ... Those `finish` functions above do not belong to `outbuf`. They are defined in the concrete derived types only. It's solely by convention that they share the same name. Yes, using `string_maker` still leads to heap allocation and `cstr_writer` to string truncation. The problem isn't solved by these. However, a string object is never the final destination. So the user could rather use another class that writes the message directly into the final destination ( output console, a log file, an LCD display or whatever ). It is not difficult to implement concrete subtypes of `outbuf`. `outbuf` is actually a type alias: template <bool NoExcept, typename CharT> class basic_outbuf; using outbuf = basic_outbuf<false, char>; using outbuf_noexcept = basic_outbuf<true, char>; That `NoExcept` template parameter is perhaps the controversial part. It is not present originally in my formatting library. Besides the destructor, `basic_outbuf` has only one virtual function: `recycle()`, and it is declared as `noexcept(NoExcept)`. This is the only effect the `NoExcept` template parameter has. All other functions are guaranteed not to throw. Hence, by taking a `outbuf_noexcept&` parameter, a function states that the destination must not throw. That might be particularly good if such object comes from another module and we must avoid exceptions crossing modules boundaries. On the other hand, if a function takes an `outbuf&`, then it also accepts `outbuf_noexcept&`, because `basic_outbuf<true, CharT>&` derives from `basic_outbuf<false, CharT>`. When using `string_maker` you can choose between the two kinds. `string_maker<true>` derives from `basic_outbuf<true, char>&`. So if any exception raises from its internal `std::string`, then it is caught by a try/catch(...) block, stored as an `exception_ptr` and rethrown by `finish()`. This has the undesirable effect of delaying its proper handling ( after all, we rather stop what's being doing as soon as possible when an error appears ). So I think the recommendation would be to use `string_maker<false>&` if possible, and `string_maker<true>&` only if necessary. The reason why I think it's controversial is that it makes `recycle()` violates the Lakos Rule. And although the Lakos Rule is not a requirement in boost (afaik), I was wondering whether this library could interest LEWG in future as well. Anyway, this whole noexcept idea is not a central part of this library and can it be removed. Now, the other topic is how to implement that `get_message` function, i.e., how to write into an `outbuf` object. One can use `puts` and `putc` functions to insert string and chars. One can also use `fmtlib` through an output iterator adapter. Or one can write directly in the buffer. But I will ask you to read the doc [3] for that. It's a quick read, quicker than this email. The repository is: https://github.com/robhz786/outbuf I would prefer it to be part of Boost.Core instead of being a standalone library, and also to remove the `outbuf` namespace. But that is up to you. Best regards, Roberto [1] The Stringify library: https://github.com/robhz786/stringify [2] The great performance of Stringify is mainly thanks to the design of outbuf ( named there as `output_buffer` ): https://robhz786.github.io/stringify/doc/html/benchmarks/benchmarks.html#be… [3] "Writing into and outbuf object" https://robhz786.github.io/outbuf/doc/html/index.html#boost_outbuf.overview…

5 13

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

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