May 2020 - Boost - lists.boost.org

CMake Announcement from Boost Steering Committee
by Jon Kalb 13 Aug '24

13 Aug '24

The libraries produced by the Boost community have had a greater impact on the way that the C++ community writes code than any other library implementation. The focus of the Boost community will always be on the libraries, but it is undeniable that we are dependent on and often limited by the infrastructure of our trade. Years ago, the move to Git was contentious; yet, it was required to improve development. In a similar vein our build system has become an impediment for many developers and users, existing and prospective. Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike. We are soliciting comments and proposals from the community to guide the process and the goals. Our desire is that the community can come to consensus by the end of the calendar year with a vision of supporting users and developers. We understand that the actual process of achieving the end goal will be long, time consuming, and not without its share of conflict. We also recognize that the Boost community is comprised of bright and passionate individuals that are eager to get involved and help get work done. The members of the Steering Committee have been encouraged by the discussions and activity surrounding CMake on the mailing lists over the years and know that many people have voiced visions. We hope that each of you rejoins the discussion to support this initiative and contributes to the common goal of improving Boost’s integration into the broader C++ ecosystem. For the Boost Steering Committee, Jon Kalb, Chair jonkalb(a)boost.org

49 200

Adding my sorting algorithm, ska_sort, to boost, attempt 2
by Malte Skarupke 24 Nov '21

24 Nov '21

Hi everyone, I started a discussion about this in October, but at the time the maintainer of the sort library was busy, then I was busy, so now it's January... I wrote a generalized version of radix sort a couple years ago and gave a talk about it here: https://www.youtube.com/watch?v=zqs87a_7zxw I would like to get a new version of that sorting algorithm into boost. It's faster than what I showed several years ago. It's also even more general and has a new interface that should be easier to extend. I uploaded the code here: https://github.com/skarupke/sort/tree/master The documentation is also already updated with new benchmark results. Let me know what's required to get this into boost. Would you like this in the form of a pull request? One of the big things that probably needs review is the interface, since radix sorting works differently than comparison based sorting. For most normal uses you just need to provide a sort key, but more complicated cases can get more complicated. I tried very hard to make everything easy, but I'd also be curious if others can come up with better ways of doing the interface. Thanks, Malte -- Malte Skarupke malteskarupke(a)fastmail.fm

8 10

[container] Proposal for ring queues
by Andrey Semashev 18 Jun '20

18 Jun '20

Hi, Some time ago I have proposed to include ring_queue and small_ring_queue containers to Boost.Container: https://github.com/boostorg/container/pull/121 The ring queues work similarly to std::queue with the main difference being that they use a ring buffer internally to store elements. The small_ring_queue also allows to allocate a static storage for a fixed amount of elements. The benefit of this is that dynamic memory allocations can be practically avoided when the number of enqueued elements does not exceed some limit. In his reply in that PR Ion was not very enthusiastic about including these containers into Boost.Container mostly because (a) there was presumably not much interest from users and (b) because the current implementation requires C++17 while Boost.Container supports C++03. I would like to ask if there is interest in the community for these kinds of containers. I know I would find them useful, and at least one person commented in the PR to the same effect. However, I would still like to see if more people need this. If there is interest, what would be the preferred course of action? 1. Should we work on inclusion into Boost.Container or maybe some other library? Candidates? Boost.CircularBuffer was mentioned in the PR, although I'm not sure it is suitable for these components. Creating a new submodule is also a possibility, although it seems like an overkill. 2. Somewhat related to p.1, what minimum C++ version is preferred. E.g. if we agree that Boost.Container is the right place for these components, I could work on lowering minimum C++ version, although C++03 would complicate things considerably. Thanks.

9 28

[review][LEAF] Review of LEAF starts today : May 22 - May 31
by Michael Caisse 08 Jun '20

08 Jun '20

The Boost formal review of Emil Dotchevski's LEAF (Lightweight Error Augmentation Framework) library will take place from May 22 through May 31st. LEAF isn't just another error reporting library in the family of expected-like types. It provides a unique take on error handling which plays into usability, flexibility, and performance. Every software developer must deal with handling errors which makes this review relevant to all. Please participate! I will be grateful to receive a review based on whatever level of effort or time you can devote. LEAF is brought to us by Emil Dotchevski, the author of Boost.Exception. Similar to Boost.Exception, this library allows arbitrary error objects to be returned; however, unlike Boost.Exception it does not require dynamic memory. The library can be used with or without exception handling. The LEAF documentation highlights the following features: * Efficient delivery of arbitrary error objects to the correct error handling scope. * No dynamic memory allocations. * Compatible with std::error_code, errno and any other error code type. * Can be used with or without exception handling. * Support for multi-thread programming. "LEAF is designed with a strong bias towards the common use case where callers of functions which may fail check for success and forward errors up the call chain but do not handle them." LEAF offers a pattern matching facility to specify which errors to handle and how to handle them. Take a look at the 5-minute Introduction. <https://zajo.github.io/leaf/#introduction> You can find the source code to be reviewed here: <https://github.com/zajo/leaf/tree/review> You can find the documentation here: <https://zajo.github.io/leaf/> The documentation includes a tutorial, examples, reference, design rationale, and comparisons to other error handling approaches/libraries. There is a benchmark document also: <https://github.com/zajo/leaf/blob/master/benchmark/benchmark.md> and a whitepaper: <https://github.com/zajo/leaf/blob/master/doc/whitepaper.md> Please provide in your review information you think is valuable to understand your choice to ACCEPT or REJECT including LEAF 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

14 42

[atomic] Bikeshedding over address-free waiting/notifying operation names
by Andrey Semashev 07 Jun '20

07 Jun '20

Hi, As some of you may know, C++20 added new waiting/notifying operations to std::atomic: wait, notify_one and notify_all. These operations are not address-free, i.e. their implementation is allowed to use process-local addresses of the atomics as keys. In particular, it means you can't use them for inter-process communication. In Boost.Atomic I intend to provide address-free variants as well, where possible, and I'm thinking about the naming scheme for them. Currently, I'm using the "_address_free" suffix, so we have wait_address_free, notify_one_address_free and notify_all_address_free. The "address-free" term comes from the C++ standard, but the resulting names seem a bit long. Maybe there are better suggestions? Thanks.

6 11

[epochs] Internal relevance in post-C++03 Boost of Boost03 components vs. standard equivalents
by Joaquin M López Muñoz 05 Jun '20

05 Jun '20

For those of you who are following the discussion on epochs, I've just prepared a report on the relevance of "legacy" components intra-Boost for these Boost libs that require C++11 (or higher) to work: https://github.com/joaquintides/boost_epoch/blob/master/boost_vs_std_intern… Quoting from the report: "It can be seen that (direct) usage of Boost03 components is residual (and in some cases due to backwards compatibility rather than for their functionality). We can draw then the conclusion that newer Boost libraries are already dismissing legacy dependencies when the standard environment offers alternatives." Best, Joaquín M López Muñoz

2 3

Re: [boost] [review][LEAF] Review of LEAF starts today : May 22 - May 31
by Bjorn Reese 02 Jun '20

02 Jun '20

On 2020-05-22 11:31, Michael Caisse via Boost wrote: > Please provide in your review information you think is valuable to > understand your choice to ACCEPT or REJECT including LEAF as a > Boost library. Please be explicit about your decision (ACCEPT or REJECT). I vote to conditionally accept LEAF into Boost. LEAF provides a new perspective on error propagation that is worth exploring in the real world. The conditions for acceptance are: 1. Provide a lower-level API for error handling which does not necessitate a pattern matching framework. I would prefer an API closer to the variant::index() and std::get<I>() combination that enables you to write the error handling as switch statements. More rationale for this request is given under the design evaluation. > - What is your evaluation of the design? LEAF propagates error objects across multiple function calls by letting the callee store the error payload directly in a stack object, called the error context, at the caller. A pointer to the error context is located in thread-local storage. When there are more error contexts on the call stack, they are daisy chained via pointers in the child error context. This is a sound design, which gives LEAF an efficient way of propagating error payloads then a failure occurs. I like that the returned error_id can be passed through C code. There is runtime overhead in creating and destroying the error contexts even when no failure occurs. Whether or not that overhead is acceptable depends on circumstances. It seems to me that the noexcept performance overhead in the successful case and the failure case are not that different (assuming the error payload is not too heavy), so it may be a good idea to choose LEAF when worst-case performance is more important than average-case performance. The more I experimented with LEAF, the more I wished that there was an error handing API with less syntatic sugar. 1. Single-stepping into a TryBlock is really cumbersome. The developer has to single-step through layers of unfamiliar templated code before reaching their own TryBlock. This interrrupts their flow. Setting a breakpoint in the TryBlock helps but is still cumbersome. 2. Some compilation errors are difficult to interpret. For example, if you accidentally omit a required return statement in one of the try_handle_all handlers, then the compiler reports the start of the try_handle_all statement and some internal LEAF voodoo. If you are experienced with reading templates errors, then you may be able to discover the erroneous handler from the LEAF template parameters in the compiler output. The LEAF handling is reminiscient of a variant visitor, but with the variants we can use index() and std::get<T> in a switch statement instead of visitation. I would like to see something similar for LEAF error contexts. I am undecided about the reliance on thread-local storage. Initially I thought that we could just replace thread-local storage with a home- made lookup table using atomics (which are generally available on OS-less platforms, whereas mutexes etc are not,) but Niall's mention of consteval made me unsure (damn you Niall ;-) However, I do not see this as a show-stopper. The try_handle_all() and try_handle_some() functions have different return values. While I understand the rationale given in the reference documentation, it may still be confusing to users if they change from one to the other. This could possibly be solved by making it more clear in the documentation. The remote_handle_all() name is confusing. I would rename it to nested_handle_all(). > - What is your evaluation of the implementation? The implementation is of high quality, and reasonably readable if you are comfortable with templates. I did not do a proper code review, so the following are random notes. Some classes (leaf::result and the internal optional) uses placement-new and explicit destructor calls. I suggest that you create your own construct_at() and destruct_at() which uses the std counterparts when available, and placement-new / explicit destruction otherwise. This will make the code more readable. std::ostream is entangled into various classes for printing. I would prefer if printing was moved into seperate X_io.hpp files to speed up compilation times when not using them. The LEAF_CONSTEXPR should be renamed to LEAF_CXX14_CONSTEXPR to align with the BOOST_CXX14_CONSTEXPR naming. Also the #if should use '>=' instead of '>'. config.h includes <Windows.h>. This should be replaced with Boost.WinAPI. > - What is your evaluation of the documentation? Overall the documentation is well-presented. The examples reconfigures std::cout to throw exceptions. That obscures the examples because now the reader has to learn LEAF and how std::cout exceptions work at the same time. It would be better to move the std::cout exception stuff into a separate example which is only about std::cout. > - What is your evaluation of the potential usefulness of the library? LEAF presents a unique error handling solution, that may be useful to certain users. I do not expect a huge user base though, as LEAF users mainly are going to be projects with requirements not met by the alternatives. > - Did you try to use the library? With which compiler(s)? Did you > have any problems? I experimented with small examples and found no compiler-related issues. > - How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? About 6 hours. Spent most time trying understanding the design than reviewing the code and documentation. > - Are you knowledgeable about the problem domain? Yes.

6 10

Relevance of platfrom-specific shared_ptr implementations
by Peter Dimov 01 Jun '20

01 Jun '20

Greetings, shared_ptr has a number of platform-specific implementations for its control block, specifically the atomic reference count manipulation: https://github.com/boostorg/smart_ptr/blob/develop/include/boost/smart_ptr/… Those have been accumulated over the years and I'd like to clean them up, remove the unused ones and fold as many of them as possible into a few generic implementations using either std::atomic, GCC atomic intrinsics (https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/_005f_005fatomic-Builtins.html) or GCC/intel sync intrinsics (https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/_005f_005fsync-Builtins.html) But I have no experience with non-x86 platforms and don't know where boost::shared_ptr is still used and which of the platform-specific implementations are still needed. (Neither do I know on which platforms the atomic and the sync intrinsics actually work, as opposed to just compile and then fail to link.) Any information along these lines is welcome. If you know of a platform where boost::shared_ptr is still used, but which supports none of the "modern" ways to implement atomic ops, please let me know. If you would like some of the plaform-specific files to be retained, please let me know. Thanks in advance.

3 2

Re: [boost] Relevance of platfrom-specific shared_ptr implementations
by Bjorn Reese 31 May '20

31 May '20

On 2020-05-31 17:18, Peter Dimov via Boost wrote: > Those have been accumulated over the years and I'd like to clean them > up, remove the unused ones and fold as many of them as possible into a > few generic implementations using either std::atomic, GCC atomic > intrinsics > (https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/_005f_005fatomic-Builtins.html) > or GCC/intel sync intrinsics > (https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/_005f_005fsync-Builtins.html) How about a fall-back to Boost.Atomic?

1 0

Re: [boost] boost reviewLEAF Review of LEAF starts today : May 22 - May 31
by Jess 29 May '20

29 May '20

Hey, big boy! My boyfriend is visiting his parents for a week and I want to get laid. You actually live just nearby. Do you want to see some of my cheeky pictures? It is in my profile On this site | | | | Online Hookup | | | Kisses, Jess

3 2