- Boost - lists.boost.org

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] Master branch now closed for 1.75.0 release
by Marshall Clow 09 Dec '20

09 Dec '20

3 5

qvm: return type for mixed scalar type vector operations
by Kai Szuttor 09 Dec '20

09 Dec '20

Hey all, concerning vector operations in boost qvm, is it possible to somehow specify the return type of a binary operator with mixed scalar input data, e.g. operator+(vec<double, 3>, vec<int, 3>) ? Could not find the customisation point to do this depending on the involved operation. Thanks in advance, Kai

2 2

Re: [boost] Boost Digest, Vol 6513, Issue 3
by Brian Wood 07 Dec '20

07 Dec '20

Peter Dimov writes: > Marshall Clow wrote: > > > I must concur with Ville here; I have had several people tell me they > won?t > > use Boost because ?it changes with every release?. > > Boost does change with every release, and I still keep using 1.38 in > several > projects of mine, but these changes are not limited to ABI at all. > Everything changes, you have to retest the whole lot, for correctness as > well as performance. > > And in general, expecting ABI stability from a collection of predominantly > header-only libraries is setting one up for severe disappointment. > > The standardized libraries are more header-only than Boost so am not sure how this isn't a rap on them also. Somehow C++ has become successful in spite of this. Brian Ebenezer Enterprises - In G-d we trust. https://github.com/Ebenezer-group/onwards

3 2

[SmartPtr] intrusive_ref_counter CounterPolicyT requirements API?
by Billy 05 Dec '20

05 Dec '20

Hi Boost, We're considering implementing our own atomic ref count for `intrusive_ref_count` [*]. A question came up. Is the `CounterPolicyT` template parameter a stable extension hook, or are users expected to strictly stick to the two provided policies of `thread_unsafe_counter` and `thread_safe_counter`? I can see that under the hood, these policy structs are trivially simple and we can just do it, but the question is really about whether the lack of documentation implies that it's a private boost detail. From https://www.boost.org/doc/libs/1_74_0/libs/smart_ptr/doc/html/smart_ptr.htm… "The second parameter is a policy that defines the nature of the reference counter. The library provides two such policies: thread_unsafe_counter and thread_safe_counter." Thanks for your time, Billy Donahue [*] Incidentally we want to increment with memory order relaxed instead of acq_rel. -- ǝnɥɐuop ʎllıq

3 4

CONTRIBUTION TOWARD YOUR OPEN SOURCE COMMUNITY.
by Prakash Choure 03 Dec '20

03 Dec '20

Hii sir/mam I am Prakash Choure and i want to contribute my skill to your open source organisation . As i am a beginner can you guide me for contribution toward your organization .My knowledge is "C" , "C++" And basic of Data structure and Algorithm . please can your team guide me. Thank you

3 2

[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