November 2020 - Boost - lists.preview.boost.org

Boost.Text is looking for a (mini-)review manager
by Zach Laine 07 Dec '22

07 Dec '22

I've made all the recommended changes to Boost.Text that came up in the review. Glen, the previous review manager, recommended a mini review of Boost.Text once I'd made those changes. If you'd like to manage the mini-review, please let me know. For everyone, including potential reviewers and review managers, here are the major changes: * All the specific review feedback issues have been addressed. * The string layer is now gone. * The text layer got a major re-work. It is now a set of template-based adaptors (basic_text<>, vs. a text typedef. etc.), which lets everyone get what they want. You can change the underlying storage type (including whatever allocator you prefer), select UTF-8 or UTF-16, and change the normalization form. Glen recommended I drop this layer, but the library is way less useful without this stuff, and these changes address all the concerns raised about the text layer in the review. The updated docs can be found here: https://tzlaine.github.io/text/doc/html/index.html Oh yeah, and I added concept constraints to the whole library when you build in C++20 mode. Zach

17 46

[review][JSON] Review of JSON starts today: Sept 14 - Sept 23
by Pranam Lashkari 09 Aug '22

09 Aug '22

Boost formal review of Vinnie Falco and Krystian Stasiowski's library JSON starts today and will run for 10 days ending on 23 Sept 2020. Both of these authors have already developed a couple of libraries which are accepted in Boost(boost beast and Static String) This library focuses on a common and popular use-case for JSON. It provides a container to hold parsed and serialised JSON types. It provides more flexibility and better benchmark performance than its competitors. JSON highlights the following features in the documentation: - Fast compilation - Require only C++11 - Fast streaming parser and serializer - Easy and safe API with allocator support - Constant-time key lookup for objects - Options to allow non-standard JSON - Compile without Boost, define BOOST_JSON_STANDALONE - Optional header-only, without linking to a library (a point I would like to add in highlight: it has cool Jason logo 😝) To quickly understand and get the flavour of the library take a look at "Quick Look" <http://master.json.cpp.al/json/usage/quick_look.html> You can find the source code to be reviewed here: <https://github.com/CPPAlliance/json/tree/master> You can find the latest documentation here: <http://master.json.cpp.al/> Benchmarks are also given in the document which can be found here: <http://master.json.cpp.al/json/benchmarks.html> Some people have also given the early reviews, the thread can be found here: <https://lists.boost.org/Archives/boost/2020/09/249745.php> Please provide in your review information you think is valuable to understand your choice to ACCEPT or REJECT including JSON 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. -- Thank you, Pranam Lashkari, https://lpranam.github.io/

21 73

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

[release] Reminder about 1.75.0 release notes
by Marshall Clow 11 Mar '21

11 Mar '21

The master branch is closing on Wednesday for the 1.75.0 release. If you have information that should go into the release notes, now’s the time to add it. Create a PR against https://github.com/boostorg/website/blob/master/feed/history/boost_1_75_0.q… <https://github.com/boostorg/website/blob/master/feed/history/boost_1_75_0.q…> — Marshall

2 3

The new Boost 17.0.0
by Antony Polukhin 10 Dec '20

10 Dec '20

Hi, == The problem. TL;DR: we are having huge troubles with usability and popularity! Quite a lot of companies forbid using Boost because: * it provides vocabulary types, that should be the same across the whole project (like shared_ptr, filesystem::path or optional). Otherwise it's hard to combine different APIs * it is huge, in consists of legacy on more than a half, with a lot of dependencies between libraries. This is extremely painful for big companies, because there's no efficient distributed build system. Each company invents it's own and/or tries to minimize headers by all means. New companies (startups) also avoid Boost: * "We are using C++17, we do not want legacy libraries with C++98 support" * Junior developers are confused by multiple vocabulary types. "Should we use boost::optional or std::optional?" * hard to upgrade, because symbols are not versioned ISO C++ WG21 community not willing to push prototypes into Boost. "We aim to establish "existing practice" and provide reference implementations so that Boost libraries are suitable for eventual standardization." - that's not really true any more. == The Solution TL;DR: we need a C++17 fork of Boost with close to 0 dependencies between libraries and namespace versioning. С++17 provides many vocabulary types, feature test macro and a bunch of features for variadic templates. All of that allows us to drop a lot of weight and fix majority of popularity and usability problems. Rule of a thumb should be: "If the C++17 provides that functionality - use the standard version". That approach would allow to loose a lot of weight, do not mess with vocabulary types and significantly reduce dependencies https://pdimov.github.io/boostdep-report/master/module-levels.html By levels: config 0 -> we probably would not need it any more assert 1 -> 0 core 2 -> 1 (or 0 if we merge it with asser) smart_ptr 4 -> 2 exception 5 -> 2 stacktrace 5 -> 2 intrusive 5 -> 2 outcome 6 -> 3 container 6 -> 3 gil 11 -> 2? context 16 -> 2? dll 17 -> 1 asio 18 -> 3? beast 19 -> 4? == The Path TL;DR: we should start the Boost17 now and ship it as we are ready. Old Boost should be still available. The new approach requires quite a lot of effort and not all the maintainers have enough time to do the migration. We should keep releasing the existing Boost, while migrating the libraries to the Boost17. The migration is not as hard as it seems. It took 2 or 3 days to make Boost.DLL work with either boost or std filesystem. It could be done in less than a day, if I do not have to support the Boost filesystem. == Action points 0) Discuss 1) Bury the idea, wait for a few years, goto 0); or make a boost17 repo with the same layout as the existing one, but without submodules 2) start the migration -- Best regards, Antony Polukhin

28 120

[release] 1.75.0 post-beta merges
by Marshall Clow 02 Dec '20

02 Dec '20

The master branch is is now open for post-beta merges, but only as described in the Post-Beta Merge Policy. See <https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy> Reminder: The master branch closes for the release on December 2nd. Full calendar here: https://www.boost.org/development/ -- The release managers

10 47

PolyCollection
by Brian Wood 30 Nov '20

30 Nov '20

Shalom Hey, is anyone using PolyCollection? I have serialization support for it: https://github.com/Ebenezer-group/onwards/tree/master/example/poly If you considered it, but chose an alternative library, what was the reason? Thanks. Brian Ebenezer Enterprises - Enjoying programming again. https://webEbenezer.net

1 0

[release] Issues
by Glen Fernandes 30 Nov '20

30 Nov '20

Need resolution: * Boost.Utility's <boost/operators.hpp> and C++20 * Boost.uBLAS tests failing C++03 and C++14. (They were failing C++20 but I cherry-picked the allocator fixes from develop, so these pass now) Glen

2 1

Re: [boost] The new Boost 17.0.0
by Glen Fernandes 29 Nov '20

29 Nov '20

On 2020-11-29, Raffi Enficiaud wrote: > 0/ For the discussions I am all for it, but I would absolutely not try > to gather consensus. Because there won't be. You definitely don't need consensus. You are free to drop C++03 and C++11 and C++14 support from Boost.Test whenever you want. We've been steadily migrating Boost libraries away from using Boost.Test to using Boost.LightweightTest for various reasons. (And have plans to migrate a few more to Boost.LightweightTest by Boost 1.76) So you can decide to require C++17 or higher for Boost.Test and not have to worry about other Boost libraries. We'll make sure their tests are still working by moving them to LWT. Just give us some warning, before you drop any support. :) Glen

1 0

Re: [boost] The new Boost 17.0.0
by Glen Fernandes 27 Nov '20

27 Nov '20

Dominique Devienne wrote: > > Glen Fernandes wrote >> I would not be in favor of a Boost distribution that requires anything >> higher than C++11 for existing libraries. i.e. Not C++17 or even >> C++14. > > But that's basically Boost as it stands, i.e. Boost 1.x. > I don't think anyone's proposing to drop that. That's Boost 1.x with more C++11 and less C++03 - with authors who choose to drop C++03 support, requiring C++11 at a minimum as per: https://pdimov.github.io/articles/phasing_out_cxx03.html This is something which Boost authors are actually acting on. e.g. Boost.Math and Boost.Multiprecision as of a future Boost 1.77 release: https://www.boost.org/users/history/version_1_73_0.html <quote> Math * IMPORTANT: C++03 support is now deprecated and will be removed from March 2021. </quote> <quote> Multiprecision * IMPORTANT: C++03 support is now deprecated and will be removed from March 2021. </quote> i.e. This is promising because people support this particular proposal enough to do something, not just for the (potentially unlimited) joy of discussing it on a list. > But isn't this just a "teething" issue? I see Ville already replied in fact. I'm following this discussion over this in C++ committee EWG reflector. I'm optimistic that people will do the right thing by users. But I prefer to make decisions based on what I know now, and what has bitten users today, with -std=c++20 and GCC 10.1 that has already shipped, not speculation about what will happen. As I said before, this is just me. C++11 (not higher, not C++17 or C++20) is just what I support and what I'd be willing to put in work towards in existing Boost libraries (and even volunteer to do for those that I do not currently maintain, but would welcome the contributions). Other authors remain free to drop support for everything besides C++17 or C++20 if they want. Glen

1 1