- Boost - lists.preview.boost.org

[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