- Boost - lists.boost.org

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