- Boost - lists.boost.org

[random] pull requests stacking up
by Jeff Garland 07 Jul '20

07 Jul '20

Just submitted a pull request for boost.random to remove dependence on system library. There's 17 open requests -- some of which are pretty easy maintenance items. Can someone give these some a look?

2 1

Boost.Beast state of play
by Richard Hodges 06 Jul '20

06 Jul '20

Dear all, As you know, Boost.Beast has a strong dependency on Boost.Asio. At the present time, Chris is working to finalise some significant changes to Asio. These changes have required some refactoring of Boost.Beast at short notice in order to continue to provide a functioning library. Boost.Asio has two significant customisation macros: BOOST_ASIO_NO_DEPRECATED and BOOST_ASIO_NO_TS_EXECTORS. The 1.74 release of Asio deprecates some classes and interfaces relevant to net.ts-style executors. In addition, it introduces execution-style executors. *There is no combination of the above flags (save for none of them) that will allow an unmodified dependent library or program to compile as of boost.asio 1.74.* As of this moment, Beast is correctly compiling all examples and passing all tests with the exception of tests relevant to c++20 coroutines, where the latest Asio commit on develop branch has one (it would appear) remaining bug. Chris has been contacted and we are awaiting a fix. Once I have this, I will be in a position to rebase Beast PR1999 onto develop/master in readiness for the 1.74. Thank you for bearing with me during my time as an unwilling hostage to fortune. -- Richard Hodges hodges.r(a)gmail.com office: +442032898513 home: +376841522 mobile: +376380212

12 23

Fixed Boost.CallableTraits is_invocable_v
by Barrett Adair 03 Jul '20

03 Jul '20

It was recently brought to my attention that the variable template version of boost::callable_traits::is_invocable was always broken. A fix has been merged to match the non-variable version of the trait. I This is a minor change. Can this be included in 1.74? https://github.com/boostorg/callable_traits/commit/6da8b5a9b8b439f8e751191a…

2 1

[thread] Release critical bug (optimized away hooks)
by Nikita Kniazev 02 Jul '20

02 Jul '20

I am informing release managers that there is a severe bug in Boost.Thread that will affect static library users built with MSVC in the next release. The bug report: https://github.com/boostorg/thread/issues/316 (TLDR: thread_specific_ptr data destructor is not called in non-Boost.Thread threads) I have opened a PR that fixes the issue https://github.com/boostorg/thread/pull/320, but got no response in weeks.

2 1

How good to use dynamic_bitset?
by Jupiter 02 Jul '20

02 Jul '20

Hi, I am working on an embedded system where I read hardware 32-bit register values represented variables in bits. Currently I am using bit shift to extract values, it is too vague to represent variables. I have been thinking to make overhaul of using dynamic bitset, is it a good idea or bad idea? Thank you. Kind regards, jupiter -- "A man can fail many times, but he isn't a failure until he begins to blame somebody else." -- John Burroughs

3 4

Boost, not LEWG
by Glen Fernandes 01 Jul '20

01 Jul '20

(A new subject, since the thread has evolved past the Text review result). I spend part of my time in the C++ standards committee. I spend part of my time in Boost. I would prefer that my time spent in Boost, and that Boost itself, be focused on its goals of serving the C++ community and Boost users (existing ones, and growing to new ones). If there is benefit of Boost to any other entity, be it the LEWG of the committee, or some organization, that's great. i.e. When Boost is adopted by some organization, or when Boost components go into the standard, that's just a bonus. But Boost itself shouldn't compromise on quality - in its review process or what it ships in a Boost distribution, to serve any of those other interests. Putting a bunch of experimental libraries into a Boost release just because people have proposed them for standardization is not something we should do. If someone wants to, they can should just start their own project full of libraries that have not undergone any kind of formal review, and convince OS distributions to start including that as part of their packages based on its own merits. In case there was any misunderstanding on this point: Zach's goals of standardization are his own, and in Boost we don't have to be concerned with them. Because we're not changing the review process because of them, and he's not asking us to. Glen

16 40

[containers] Addition of a dense map implementation
by Jeremy Junac 30 Jun '20

30 Jun '20

Hi, While working on different projects in which performance is key, I came to realize that the efficiency of the associative containers that are available in the STL can be improved. For instance, it is well know that neither std::unordered_map nor std::map are cache-friendly. It isn't that hard to find implementations that are faster, for instance flat_map, already in Boost.Containers. However, I would be interested in another implementation, a "Dense Map", similar to the one we can find in SparseHash (https://github.com/sparsehash/sparsehash) or in LLVM's ADT (https://llvm.org/doxygen/DenseMap_8h.html) For sure I am not the only one attracted to such implementation, as we can find several ones in the internet, although, it really lacks of "one true generic implementation". SparseHash doesn't seem that maintained anymore and, well, LLVM is LLVM. Hence, instead of having yet another implementation of my own, I would rather have one in Boost, to ensure long-term maintainability. I know that this particular subject was kind of already discussed in this thread from 2016 (https://lists.boost.org/Archives/boost//2016/01/227076.php) and some very good points were made. But in the end, years have passed, and we still don't have an alternative, so in my opinion an implementation in Boost would actually be something to consider. Please let me know what you think about that. I am open to any other ideas, and in case we agree on the addition of a new implementation, I would actually be pleased to contribute. Best regards, Jeremy Junac

2 1

Re: [boost] Boost, not LEWG
by pbristow＠hetp.u-net.com 29 Jun '20

29 Jun '20

> -----Original Message----- > From: Boost <boost-bounces(a)lists.boost.org> On Behalf Of Vinnie Falco via Boost > Sent: 29 June 2020 06:40 > To: boost(a)lists.boost.org List <boost(a)lists.boost.org> > Cc: Vinnie Falco <vinnie.falco(a)gmail.com> > Subject: Re: [boost] [OT] Re: Boost, not LEWG > > On Sun, Jun 28, 2020 at 10:22 PM Schrom, Brian T via Boost <boost(a)lists.boost.org> wrote: > > My suggestion is.... > > Yeah mailing lists are nice for the monotonically decreasing set of older engineers used to the > anachronism but they are not in any way shape or form attractive for bringing in new, young blood. As one no longer in the first flush of youth (and I suspect a target of this barb 😉 ), I'm not sure that this is the most important issue. We seem to have shifted to CVS, SVN and now GIT and GitHub a little ahead of the curve (and I note that GitHub gives you an email interface as well as a web one). I suspect that 'If it ain't broke, don't fix it." applies to the mailing list/forum issue. I think that the key problem with reviews in finding people who are knowledgeable enough to make useful comments. Often users are best-informed we can get. Too many reviews are theoretical analyses, not based on any 'real-life' use that would expose strengths and weaknesses. There has long been a chicken and egg issue, you don't get many users until a library is in Boost, and so you don't get much informed feedback. I still favor some sort of 'Candidate' status, formalizing the current 'Acceptance subject to changes' status, but giving wider visibility on the Boost GitHub site. Boost has spawned several standards, but also provided many libraries that are entirely unsuitable for standardization. I hope this will continue. Paul Bristow PS I have always been impressed by the overwhelmingly politeness of interchanges on Boost and WG21 etc, in contrast to the internet in general. I believe that Boost is also entirely gender and color-blind.

6 6

[text] [review] Text formal review result
by Glen Fernandes 29 Jun '20

29 Jun '20

Many thanks to Zach for submitting his third library, Text, for Boost formal review. And thank you to the Boost community for participating. You can jump to result at the end of this email. The review period ran from June 11 to June 20 and we received a total of four reviews (three within the period). I won't summarise individual points, all reviews are accessible in the Boost list archives. 1. Emil Dotchevski submitted an early review, on June 3. He voted to accept the entire library with no conditions. 2. Rainer Deyke submitted a review on June 12. He voted to accept only the Unicode algorithms. 3. Phil Endecott submitted a review on June 18. He voted to accept only the UTF transcoding algorithms, and accept the Unicode layer providing the license issue is resolved. 4. JeanHeyd Meneide submitted a review after the review period ended, on June 21. He voted to accept the Unicode layer, and require that the text layer (if accepted) use std::string instead. I received no private reviews, but one email expressing concern about the copyright issue and eligibility for review. My thanks to Emil, Rainer, Phil, and JeanHeyd for your reviews. Thanks also to Gavin Lambert, Vinnie Falco, Alexander Grund, Villie Voutilainen, and everyone who participated in the discussion. The following points had the most weight in the review result that follows: 1. No desire for the string layer The bar for a custom string type is high. On a minor note presents incompatibilities with interfaces using std::string. On a major note a string replacement should give users things they currently depend on in std::basic_string. One of these is the ability to control dynamic allocations. Another is working with strings larger than 2GB. Allocators are not only about performance; i.e. the argument that supporting custom allocators would compromise the performance of the implementation is not enough to justify their absence. Users have the need to choose which area of dynamic memory their objects live in. In some cases users have a requirement that all dynamic allocations go through a custom (and stateful) allocator. JeanHeyd mentioned the now-deprecated wstring_convert functions which, despite their shortcomings, were usable. I filed LWG 2226 (http://wg21.link/lwg2226) years ago while at Microsoft because we had to reject its use in such a project where every dynamic allocation had to support stateful allocators, and wstring_convert did not. The end result was the developer reimplementing the functionality with proper support for stateful allocators. Supporting customizing allocation doesn't necessarily have to involve the current allocator model that containers or other standard library allocator-aware facilities support. As long as it provides the user with a similar level of control. 2. No strong acceptance for the text layer I won't repeat the points here. There was no strong desire expressed to have the text layer in Boost. The compromise to have it backed by std::string was still expressed in light of several shortcomings. 3. Portions of the library under a non-BSL license Phil identified three cases where the library did not have appropriate licensing. One was a simple omission, another has been resolved by the relevant code being relicensed under the BSL, but the other is still pending. We have a strict requirement for Boost licensing of code and data in our libraries that ship in the Boost distribution, and we cannot compromise on this. Zach understands this (he's authored two successful Boost libraries) and I'm confident he will address this. 4. A strong desire to have the Unicode layer in Boost Especially the encoding transcoding, the Unicode algorithms part of the library was well received. The reviews - though small in number - have convinced me of the value of accepting this layer of the library, provided the submission in question (all code and data) is licensed entirely under the BSL. A minor issue: 1. For a library of this size (all three layers are of non-trivial implementation size), I hoped for more reviews and participation. Rather than extend the review period by an additional week, the feedback received above lead me to believe that for Boost's and Zach's benefit, the result below and the prescribed course of action would be better: The result of this review is to reject the Text library in its current form, but to ask Zach to submit a subset of the library containing only the Unicode layer for mini-review, incorporating the feedback pertaining to it in this review. Where all of the code and data is licensed only under the BSL. The review wizard has the ability to grant a 5-day mini-review instead of a full 10-day review, and I've petitioned Mateusz to grant that Zach have this opportunity if he chooses for a second review of a library with just the Unicode layer. The text layer (backed by std::string, but ideally designed one that does not inhibit use of custom allocators ) could be reviewed as a separate library, to improve the chances of getting the Unicode algorithms in the hands of Boost users. My thanks once again to Zach for submitting his Text library for a review, and I hope that the second time's the charm. Glen

15 39

Re: [boost] [text] [review] Text formal review result
by Nikita Kniazev 28 Jun '20

28 Jun '20

> Mailing list sucks. I agree with this. I almost never reply to the mail list because I really have no idea how to do it without top-posting (I subscribed to daily digests). Simply, mail lists have only a single advantage -- everyone has an email. No code highlighting, quotes in digest are a bunch of '>' symbols and no threading. > We absolutely should move to a forum on boost.org for all things, > import as much as we can from the mailing list (as far back as > possible) into the forum, and then cease the use of the mailing list > forever. Anyone who emails the list should get an automated reply that > says "Please register for the wonderful forums at boost.org" etc With something like Discourse you can still use the old and good email to reply to posts (like on GitHub) and even to create threads ( https://meta.discourse.org/t/can-i-start-a-new-topic-by-sending-an-email-me… ).

1 0