пт, 27 нояб. 2020 г. в 12:46, Hans Dembinski :

...

On 27. Nov 2020, at 09:58, Antony Polukhin via Boost wrote:

== The Solution TL;DR: we need a C++17 fork of Boost with close to 0 dependencies between libraries and namespace versioning.

I am personally fine with a C++17 fork, but that means dropping Boost Serialization among other things, right?

Not really. Serialization library can not be replaced with C++17 Standard library, so we can move it to Boost17. This would require some effort in dropping MPL dependency or replacing it with Mp11, untying it from boost::variant and others

Boost Histogram has level 2 dependencies without Boost Serialization, which is opt-in. With Boost Serialization is has level 18, because Boost Serialization depends on the world. AFAIK rewriting Boost Serialization to drop Boost MPL would be a major effort.

I'm doubting that. A quick search shows that Serialization mostly uses MPL things that are available in C++17 (like enable_if, true_type and static_assert). Effort is required, but it is bearable. Because of that effort we need time to make Boost17 usable. I'd be able to move stacktrace and dll libraries in a few weeks. Mp11, Pfr and Predef are ready to move. It may take much more time to move Histogram or GIL

Besides that, demanding 0 dependencies has serious drawbacks. Boost Histogram uses Boost functionality where there is no equivalent in the stdlib, not even in C++17 (Boost config, Boost throw_exception, Boost mp11, Boost core). I already reimplemented functionality in Boost Histogram that was originally found in other Boost libs to reduce coupling, like Boost Iterator and Boost Multiprecision. Boost Beast does this, too, it has its own variant type and more.

Not 0, close to 0. It is fine to reuse libraries if there is no Standard Library replacement. It is not fine to use Boost version, if there is a close alternative in the C++17

A non-fundamental library like Histogram or Beast has the choice to either suffer a significant loss of functionality or use its own private implementation of Boost functionality to give the appearance of low dependencies. This inflates the private code of these libraries and maintaining private (duplicated) implementations is frankly crazy. We bundle Boost to make use of **synergies** between the libs. I should not use my private (potentially buggy) implementation of Boost iterator, I should use the official maintained (and hopefully less buggy) one.

Yep, we need to keep being reasonable during migration.

Best regards, Hans

-- Best regards, Antony Polukhin

пт, 27 нояб. 2020 г. в 13:36, Andrey Semashev via Boost :

We went over this multiple times. I'll just reiterate that I disagree with this approach. Many Boost libraries are superior to std equivalents, and I want to keep using them inside and outside Boost. Also, I don't see why Boost libraries are not allowed to exist as an extension over the std equivalents.

That's why we are not dropping the existing Boost. There are many users who share your point of view. But there are others, and we have more and more of them year over year.

...

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

That's wishful thinking, unfortunately. Compiler bugs still exist, and C++17 support level is not uniform across compilers. Moving forward, later C++ versions are also not uniformly implemented.

We have feature test macro and Predef. IMO that's enough.

...

assert 1 -> 0

I'm not aware of a standard replacement of Boost.Assert. <cassert> is not one.

Assert drops dependency on Config and moves to Level 0. I'm not proposing to purge the library. -- Best regards, Antony Polukhin

Gesendet: Freitag, 27. November 2020 um 11:36 Uhr Von: "Andrey Semashev via Boost"

On 11/27/20 11:58 AM, Antony Polukhin via Boost wrote:

...

== 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".

We went over this multiple times. I'll just reiterate that I disagree with this approach. Many Boost libraries are superior to std equivalents, and I want to keep using them inside and outside Boost. Also, I don't see why Boost libraries are not allowed to exist as an extension over the std equivalents.

Speaking for me in particular: What does annoy me, is if a boost library uses the boost equivalent of a standard library vocabulary type in its interface. E.g. boost::string_view instead of std::string_view or boost::chrono::duration instead of std::chrono::duration. As far as other duplications go: If (and I really want to stress the if) using the boost version adds significant compiletime or binary size overhead compared to the std version then I'd also prefer if the std versions were used in the implementation where possible. Otherwise I as a user don't really care. The difference in compiletime might happen when the boost version using some complex TMP (especially mpl) hacks whereas the std version can use more efficient language constructs - and of course the std version almost always ends up in my translation unit anyway, so compiling the boost equivalent is just some additional work, but I don't have any experimental data to show if there are actually any significant gains possible inpractice. Regarding the proposal in general: Let me play the devil's advocate and ask, how many active boost maintainers there are left. Are there enough to pull through with something like that, without loosing a big chunk of the libs for which there isn't a good c++17 equivalent yet (or ever). Actually, that would be an argument for removing internal dependencies on boost libs that have a c++17 equivalent: Reduced overall maintenence overhead for boost once you are there and more flexibility for individual libs. But of course I'm certainly not able to predict, if it would be a net win or not. Best Mike

Mathias Gaunard wrote:

A tangent, but I'd rather use a simple and standard component that is used throughout all kinds of C and C++ code that some boost-specific thing that adds zero value.

The purpose of BOOST_ASSERT is to provide the ability for controlling assertions in Boost libraries without affecting all other uses of the standard `assert`.

пт, 27 нояб. 2020 г. в 14:09, Francesco Guerrieri via Boost :

It's almost impossible to not top post from the phone, sorry!

I am just a simple user, even if long dated. For what is worth I don't agree with the goal of 0 dependencies between boost libraries: this for me goes against the spirit of the language. I agree that dependencies can grow out of control and the unnecessary proliferation should be avoided (a lot of work has been done on that)...

OK, how about a goal "Use the C++17 standard version whenever possible"? With that goal we would reach the required result, but the goal wording is less obscure. -- Best regards, Antony Polukhin

Dominique Devienne via Boost said: (by the date of Fri, 27 Nov 2020 15:04:50 +0100)

Hi. I like that idea. I'm on C++17 and Boost 1.74, likely for a long time*, so a C++17 Boost fork would work better for me, but C++20's modules and concepts do seem like a stronger base for a Boost 2.0 and would yield bigger bang for the buck, longer term.

I completely agree. Let the boost versions 1.74, 1.75, 1.76 etc remain C++Old compliant, and can be maintained as long as one wishes to maintain it. And start the 2.00, 2.01, 2.02 boost releases versioning which takes a new breath by fully utilizing the new C++20 features. No workarounds broken compilers is also a good idea. -- # Janek Kozicki http://janek.kozicki.pl/

Gesendet: Freitag, 27. November 2020 um 13:26 Uhr Von: "Niall Douglas via Boost"

On 27/11/2020 12:19, Vinnie Falco via Boost wrote:

...

On Fri, Nov 27, 2020 at 12:58 AM Antony Polukhin via Boost wrote:

...

asio 18 -> 3? beast 19 -> 4?

Beast depends on Asio, so you will have to convince Christopher Kohlhoff to go along with this idea for Asio.

If I were Chris K, I'd respond "If you want to use Boost.ASIO with the standard C++ library, please go use Standalone ASIO. Boost.ASIO is specifically ASIO targeting Boost".

Whats the problem? Shouldn't that essentially just be a matter of tweaking boostify.pl to replace fewer std types from the no-boost reference code with boost equivalents than it currently does? Or is there more to it? Best Michael

On 12/1/2020 2:44 PM, Antony Polukhin via Boost wrote:

On Fri, Nov 27, 2020, 15:54 Edward Diener via Boost wrote:

...

On 11/27/2020 3:58 AM, Antony Polukhin via Boost wrote:

...

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"

If a library provides support for C++98/2003 but also works perfectly fine using C++17, please explain to me what is wrong with using that library when compiling for C++17 ? Thank you !

For example, that library may use boost/type_traits.hpp and boost/mpl/*. Those headers include a bunch of text and variadic templates emulation, and compile times getting drastically worse.

Another example: library that uses boost/optional.hpp includes ~500kB of code. To make things funnier, ln some standard libraries inclusion of boost/optional.hpp leads to inclusion of <optiknal>, so removing the dependency drops 500kb of text from each translation unit.

Final example: library work in c++98 and it almost does not depend on other Boost libraries. Great! It's a perfect candidate for Boost17.

Nothing wrong in c++98 support, the problem is in the dependencies and huge translation units to compile.

So if you use in a C++17 project a Boost library which supports C++98/C++03 you have huge translation units but if you use a Boost library which supports C++11 on up or if you use C++ standard libraries which often depend on each other you never have huge translation units. Is that what you are saying ?

...

* hard to upgrade, because symbols are not versioned

...

Versioned symbols ?

If you are using a system package that relies on Boost, then you can not upgrade Boost. For example mongo library uses Boost 1.45 and you wish to use Boost 1.74 => you've got problems.

Of course if you use the mongo library, whatever it is, with the C++ standard library it automatically works with whatever the latest C++ standard library is installed but if you use mongo with Boost it only works with Boost 1.45 and not the latest Boost. And this is Boost's fault no doubt !

Linker may merge not ABI compatible Boost symbols, leading to breakages. More specifically, the layout of Boost.Variant changed multiple times since 1.45, but the signature of the boost::apply_visitor function did not change. As a result you get ODR-violation.

Are you saying that Boost is not ABI compatible between releases but any compiler's C++ standard library is always ABI compatible between releases ?

On 12/1/2020 4:39 PM, Antony Polukhin via Boost wrote:

On Wed, Dec 2, 2020, 00:22 Edward Diener via Boost wrote:

...

On 12/1/2020 2:44 PM, Antony Polukhin via Boost wrote:

...

On Fri, Nov 27, 2020, 15:54 Edward Diener via Boost

...

If a library provides support for C++98/2003 but also works perfectly fine using C++17, please explain to me what is wrong with using that library when compiling for C++17 ? Thank you !

For example, that library may use boost/type_traits.hpp and boost/mpl/*. Those headers include a bunch of text and variadic templates emulation, and compile times getting drastically worse.

Another example: library that uses boost/optional.hpp includes ~500kB of code. To make things funnier, ln some standard libraries inclusion of boost/optional.hpp leads to inclusion of <optiknal>, so removing the dependency drops 500kb of text from each translation unit.

Final example: library work in c++98 and it almost does not depend on other Boost libraries. Great! It's a perfect candidate for Boost17.

Nothing wrong in c++98 support, the problem is in the dependencies and huge translation units to compile.

So if you use in a C++17 project a Boost library which supports C++98/C++03 you have huge translation units but if you use a Boost library which supports C++11 on up or if you use C++ standard libraries which often depend on each other you never have huge translation units. Is that what you are saying ?

More or less. Users will use the standard libraries anyway, adding Boost libraries that duplicate the functionality increase the size of translation unit. If you have no standard alternative - you use Boost, you have no choice.

I am not against C++98/C++03 libraries being upgraded to C++11 in order to use C++ standard library equivalents to Boost types. Nor am I against a separate C++11 library of a current C++98/C++03 library being added to Boost which uses C++ standard library equivalents to Boost types and in all other respects is the same as the original library. But the latter solution does require extra maintenance and who is going to do that ?

...

Linker may merge not ABI

...

compatible Boost symbols, leading to breakages. More specifically, the layout of Boost.Variant changed multiple times since 1.45, but the signature of the boost::apply_visitor function did not change. As a result you get ODR-violation.

Are you saying that Boost is not ABI compatible between releases but any compiler's C++ standard library is always ABI compatible between releases ?

Not any, but many.

I believe the great majority of Boost libraries attempt to maintain ABI compatibility between releases. But just like with compilers it is not always possible between releases.

On 12/2/2020 5:12 AM, Andrey Semashev via Boost wrote:

On 12/2/20 1:21 AM, Edward Diener via Boost wrote:

...

I believe the great majority of Boost libraries attempt to maintain ABI compatibility between releases.

My impression is the opposite. Boost has never declared backward ABI or API compatibility. There's a reason why binary distributions of Boost append a version tag that matches Boost version to packages and binaries.

Whether Boost declares it or not I do not think Boost libraries change the API or ABI very often between releases and, if they do, they will notify the end-user about it. But of course you are correct that their is no attempt at a policy that claims compatibility between releases.

...

But just like with compilers it is not always possible between releases.

You have to give credit to libstdc++ developers at the very least. It maintains backward ABI compatibility across all C++ standard versions and across libstdc++ releases for many years. I think, libc++ also does the same, although I'm not following its development.

So are you telling me that if I have gcc-10.2 I should be able to use the gcc-5.1 libstdc without any ABI problems ?

On 12/2/2020 9:42 AM, Andrey Semashev via Boost wrote:

On 12/2/20 5:08 PM, Edward Diener via Boost wrote:

...

On 12/2/2020 5:12 AM, Andrey Semashev via Boost wrote:

...

On 12/2/20 1:21 AM, Edward Diener via Boost wrote:

...

I believe the great majority of Boost libraries attempt to maintain ABI compatibility between releases.

My impression is the opposite. Boost has never declared backward ABI or API compatibility. There's a reason why binary distributions of Boost append a version tag that matches Boost version to packages and binaries.

Whether Boost declares it or not I do not think Boost libraries change the API or ABI very often between releases and, if they do, they will notify the end-user about it.

No, not really. Internal changes are often not reflected in the release notes at all, while they may affect ABI.

If the binary interface between the end-user and a library remains the same I do not think changes to some internal structure or internal functionality matters. Can you give an example where it does ?

You may have an impression of stability because many Boost libraries don't change that much (e.g. due to lack of maintenance). This is not a result of a maintenance decision, but a product of the lack of development. Hence this is not a guarantee or promise or whatever that ABI/API is stable.

...

So are you telling me that if I have gcc-10.2 I should be able to use the gcc-5.1 libstdc without any ABI problems ?

No, because a program compiled with gcc 10 may use symbols of the standard library that were not available in gcc 5. But you could do the other way around - have your program compiled by gcc 5 and run it with libstdc++ from gcc 10. People do this rather often, when they install pre-compiled binaries from external sources (i.e. not from the distro repositories).

There are a few ABI changes that were made in gcc (the compiler, not libstdc++), but there are options to highlight code affected by them or switch to the older behavior. I did not research whether libstdc++ is affected by those, but I would assume either not affected or the necessary workarounds are in place.

On 12/2/2020 10:36 AM, Andrey Semashev via Boost wrote:

On 12/2/20 5:55 PM, Edward Diener via Boost wrote:

...

On 12/2/2020 9:42 AM, Andrey Semashev via Boost wrote:

...

On 12/2/20 5:08 PM, Edward Diener via Boost wrote:

...

On 12/2/2020 5:12 AM, Andrey Semashev via Boost wrote:

...

On 12/2/20 1:21 AM, Edward Diener via Boost wrote:

...

I believe the great majority of Boost libraries attempt to maintain ABI compatibility between releases.

My impression is the opposite. Boost has never declared backward ABI or API compatibility. There's a reason why binary distributions of Boost append a version tag that matches Boost version to packages and binaries.

Whether Boost declares it or not I do not think Boost libraries change the API or ABI very often between releases and, if they do, they will notify the end-user about it.

No, not really. Internal changes are often not reflected in the release notes at all, while they may affect ABI.

If the binary interface between the end-user and a library remains the same I do not think changes to some internal structure or internal functionality matters. Can you give an example where it does ?

In Boost.Filesystem (https://github.com/boostorg/filesystem/commit/498a090b531833355ea27cea94d044...) directory iterators switched from shared_ptr to intrusive_ptr internally. This changed the ABI but not API, and this change would not have been detected by the linker since this change would not affect library symbols. Even ignoring Boost.Filesystem library, if some part of user's code is not recompiled with the new library headers, there would be ABI mismatch and related problems.

But if the end-user's code does not reference the internal directory iterators why does the end-user code need to recompile itself to match the change to the internal ABI ?

On 3/12/2020 3:55 am, Edward Diener wrote:

If the binary interface between the end-user and a library remains the same I do not think changes to some internal structure or internal functionality matters. Can you give an example where it does ?

Any change to members (of any kind, including private) affects the layout and size of a class, which is a breaking change to the class ABI. This causes all manner of subtle ODR problems as soon as you try to mix a translation unit compiled with the old class definition with one compiled with the new class definition, even if at first glance it seems like the consuming code never directly accesses those members. Defaulted constructors/destructors/operators and inlined methods of any kind are the biggest culprits of issues, but it's not limited to those. And only if you're very lucky will you see a linker error about a missing symbol. It's most likely that there will be no errors at all until something crashes or subtly misbehaves at runtime. (This is fundamentally an issue with C++ itself, where it favours performance over robustness, which is at the heart of the ODR.) And yes, historically Boost has made absolutely no guarantees of ABI stability whatsoever between releases (read: assume it will always break ABI), although it may sometimes work by coincidence simply due to changes being relatively rare in stable libraries.

On Wed, Dec 2, 2020 at 3:12 AM Andrey Semashev via Boost < boost@lists.boost.org> wrote:

On 12/2/20 1:21 AM, Edward Diener via Boost wrote:

...

I believe the great majority of Boost libraries attempt to maintain ABI compatibility between releases.

My impression is the opposite. Boost has never declared backward ABI or API compatibility. There's a reason why binary distributions of Boost append a version tag that matches Boost version to packages and binaries.

I agree -- it's explicitly not a boost goal.

But just like with compilers it is not

...

always possible between releases.

You have to give credit to libstdc++ developers at the very least. It maintains backward ABI compatibility across all C++ standard versions and across libstdc++ releases for many years. I think, libc++ also does the same, although I'm not following its development.

Well 'the credit' is that anything that changes the std:: ABI is a fight in the committee -- there's even a special working group - so real tough to get an ABI change into the standard. To me it makes sense that boost should break ABI like mad and the standard should strive for more stability with occasional ABI breaks.

On Wed, Dec 2, 2020 at 8:50 AM Andrey Semashev via Boost < boost@lists.boost.org> wrote:

On 12/2/20 6:42 PM, Jeff Garland via Boost wrote:

...

On Wed, Dec 2, 2020 at 3:12 AM Andrey Semashev via Boost < boost@lists.boost.org> wrote:

...

You have to give credit to libstdc++ developers at the very least. It maintains backward ABI compatibility across all C++ standard versions and across libstdc++ releases for many years. I think, libc++ also does the same, although I'm not following its development.

Well 'the credit' is that anything that changes the std:: ABI is a fight in the committee -- there's even a special working group - so real tough to get an ABI change into the standard. To me it makes sense that boost should break ABI like mad and the standard should strive for more stability with occasional ABI breaks.

Although the committee does monitor changes that may affect ABI in real implementations, the standard does not define the ABI. It is implementors burden to maintain a stable ABI.

It doesn't need to define ABI for it to be real -- the library implementers are very aggressive in limiting ABI breaks. The former LEWG chair (Titus) was quite vocal in wanting to remove this constraint leading to vigorous debates and a vote which basically affirmed that the committee was very split on the matter, but preferred stability. As an example of this, libstdc++ had to switch their basic_string to a

non-reference counted implementation when they added support for C++11, and they had to maintain both versions ever since. The standard, obviously, only defines one basic_string.

And that was the last ABI break that made it thru the committee -- so a good decade ago.

On Wed, 2 Dec 2020 at 17:58, Jeff Garland via Boost wrote:

It doesn't need to define ABI for it to be real -- the library implementers are very aggressive in limiting ABI breaks. The former LEWG chair (Titus) was quite vocal in wanting to remove this constraint leading to vigorous debates and a vote which basically affirmed that the committee was very split on the matter, but preferred stability.

ABI breaks shift the burden and pain downstream. There's a curious correlation between the amount of downstream levels that some developers have and their reluctance to break ABI when they can avoid it. There's a non-zero amount of users to whom the lack of ABI stability in boost is a reason not to touch boost with a ten-foot pole. "Breaking ABI like mad" is nice and fine if all your users are developers that like rebuilding their world often. When the vast majority of your users are not developers, the situation may be quite different. And that difference multiplies when you're trying to provide libraries for users who provide them combined with something else to other downstream users further apart from you the upstream library vendor.

On Dec 2, 2020, at 10:08 AM, Peter Dimov via Boost wrote:

Ville Voutilainen wrote:

...

There's a non-zero amount of users to whom the lack of ABI stability in boost is a reason not to touch boost with a ten-foot pole.

That's not common. It's very unusual to want to upgrade Boost without recompiling the rest of the software. Typically the people who want ABI stability use the system-supplied Boost and it's fixed for the particular distro.

I must concur with Ville here; I have had several people tell me they won’t use Boost because “it changes with every release”. [ Personally, I don’t have a lot of sympathy for this attitude, but it *does* exist, and is not an isolated incident. ] — Marshall

On Wed, Dec 2, 2020 at 11:17 AM Marshall Clow via Boost < boost@lists.boost.org> wrote:

On Dec 2, 2020, at 10:08 AM, Peter Dimov via Boost wrote:

...

Ville Voutilainen wrote:

...

There's a non-zero amount of users to whom the lack of ABI stability in

boost is a reason not to touch boost with a ten-foot pole.

...

That's not common. It's very unusual to want to upgrade Boost without

recompiling the rest of the software. Typically the people who want ABI stability use the system-supplied Boost and it's fixed for the particular distro.

I must concur with Ville here; I have had several people tell me they won’t use Boost because “it changes with every release”.

[ Personally, I don’t have a lot of sympathy for this attitude, but it *does* exist, and is not an isolated incident. ]

— Marshall

And I mentioned in a different reply, I think it's more about API instability for boost libraries -- or both. And I don't have much sympathy either. You've got the choice to stay on an older version. Or patch together your own. Awhile back I patched an older version of endian into a newer version of boost because the newer version removed features I was using and didn't have time to fix during the upgrade. The fact that it's open source gives people a lot of freedom.

On 28.11.20 00:25, Emil Dotchevski via Boost wrote:

Deleting support for C++11 and older versions means breaking user code. Therefore, forking means fracturing of the community. I don't see how this is helpful to the users.

The current status quo is that individual library maintainers can choose to drop support for old C++ standards at any time. This means that user are often stuck on a specific version of the 1.x line. From a user perspective, forking is an improvement over the status quo: it means that Boost can guarantee that the 1.x line can stop dropping support for old C++ standards, making it relatively safe to upgrade within the 1.x line. One of the big weaknesses of Boost, from a user perspective, is the way releases are handled, with each release potentially containing breaking changes bundled along with the bug fixes and new features. What I'd really like to see is a policy where breaking changes are reserved for major (x.0) versions, with minor (x.y) versions only containing bug fixes and backwards-compatible new features. Since the major versions aren't expected to be completely backwards-compatible, they could make relatively bold changes like dropping obsolete libraries. (The drawback of this approach is of course that on the developer side it's a lot more work to support multiple versions of a library in parallel. I have deliberately taken a user-centric view here.) -- Rainer Deyke (rainerd@eldwood.com)

On 28.11.20 19:07, Peter Dimov via Boost wrote:

Rainer Deyke wrote:

...

From a user perspective, forking is an improvement over the status quo: it means that Boost can guarantee that the 1.x line can stop dropping support for old C++ standards, making it relatively safe to upgrade within the 1.x line.

This is only an improvement in the imaginary world where we have enough resources to maintain two forks. In reality, we have trouble maintaining one.

Yes, that's why I wrote "from a user perspective". I'm not saying that this a practicable solution. I'm just saying that it would be nice if it were. I think it /might/ be possible to mark some releases (maybe one every two years?) as "major", and delay the release of breaking changes for the next major release. Actively developing on two or more branches in parallel is probably just fantasy though. -- Rainer Deyke (rainerd@eldwood.com)

On 11/28/2020 4:59 PM, Peter Dimov via Boost wrote:

Rainer Deyke wrote:

...

...

Rainer Deyke wrote:

...

From a user perspective, forking is an improvement over the status quo: >> it means that Boost can guarantee that the 1.x line can stop dropping >> support for old C++ standards, making it relatively safe to upgrade >> within the 1.x line.

This is only an improvement in the imaginary world where we have enough > resources to maintain two forks. In reality, we have trouble

On 28.11.20 19:07, Peter Dimov via Boost wrote: maintaining > one.

Yes, that's why I wrote "from a user perspective".  I'm not saying that this a practicable solution.  I'm just saying that it would be nice if it were.

Nice for the end user, perhaps, but intermediate libraries are now forced to choose between using boost or boost2, or maintaining two versions.

My alternative idea of "nice to have" is a single Boost library that can use either boost or std components in its interface. That's not always possible to obtain though.

ROFL. "How would you link all the variations of that library if the library were not a header-only library. You would have to have a different name for each combination and the number of combinations would proliferate to an unusable number. What a pipe dream you have !" <g>

On Dec 1, 2020, at 22:05, Antony Polukhin via Boost wrote:

...

My alternative idea of "nice to have" is a single Boost library that can use either boost or std components in its interface. That's not always possible to obtain though.

I've tried that and it kind of works. There are still problems: * users have to use macro to customize the library * bcp still pulls in the Boost alternatives * code redability suffers from typedefs * you still kind of have two different libraries

Here is a case study. Some while ago I proposed to Steven Watanabe, the maintainer of boost.random to produce a version of my MIXMAX random number generator for inclusion. The software at that point was plain vanilla C++11. After a go-ahead from Steven I added a series of boosticisms in order to make the stuff conform to how things were done in boost.random. The only sticky point was std:array. I was informed by Steven that the library must work with C++03 and there I had to use boost::array or something else. Not wanting to use typedefs and macros such as the below, #ifndef BOOST_NO_CXX11_HDR_ARRAY #include <array> #define mixmaxarray std::array #else #include #define mixmaxarray boost::array #endif ...#undef mixmaxarray The other alternative kindly proposed by Steven was: namespace boost { namespace random { namespace arrayns = std; } } And yet another suggestion was to turn off inclusion of MIXMAX under C++03, but that required messing with [[config.requires cxx11_hdr_array]] in the jamfile for tests which I learned had been a source of problems back in 2016! http://boost.2283326.n4.nabble.com/question-regarding-quot-requires-cxx11-hd... http://boost.2283326.n4.nabble.com/question-regarding-quot-requires-cxx11-hd... So, what was the least disruptive solution? Yes, going with boost::array everywhere. Best Regards, Kostas

On Dec 2, 2020, at 00:01, Edward Diener via Boost wrote:

OTOH if he is compiling with C++11 on up he is probably using std::random instead of boost::random so your choice is right.

I am providing my new, better RNG in boost::random since convincing LWG to include it in std::random will take some while longer ;) (btw, std:array is not a part of any interfaces of boost::random it is a purely an internal issue which, yes, I know, is not considered as serious)

On 2/12/2020 11:01 am, Edward Diener wrote:

On 12/1/2020 4:36 PM, Kostas Savvidis wrote:

...

#ifndef BOOST_NO_CXX11_HDR_ARRAY #include <array> #define mixmaxarray std::array #else #include #define mixmaxarray boost::array #endif ...#undef mixmaxarray

The other alternative kindly proposed by Steven was: namespace boost { namespace random { namespace arrayns = std; } }

I wrote a library called cxx_dual ( https://github.com/eldiener/cxx_dual ) to solve a problem like yours, but it did not meet with general approval. With cxx_dual your code above could have been:

#include #define mixmaxarray cxxd_array_ns::array

You shouldn't use #define for that sort of thing anyway. Define a local typedef: namespace boost { namespace mylib { typedef cxxd_array_ns::array mixmaxarray; } } (Or a "using" alias, if you can assume C++11.) However this is only actually correct behaviour if it's a header-only library. In a compiled library, what you actually should do is something closer to this: // header file #if SOME_CONDITION typedef std::foo myfoo; namespace detail1 { class aclass { ...; std::foo m_foo; }; } typedef detail1::aclass aclass; #else typedef boost::foo myfoo; namespace detail2 { class aclass { ...; boost::foo m_foo; }; } typedef detail2::aclass aclass; #endif class commonclass { void method(myfoo const& x); }; // cpp file 1 #if CAN_COMPILE_STD_FOO // or equivalently set build rules to skip this file if std::foo doesn't // exist at build time void commonclass::method(std::foo const& x) { ... } // implementation for detail1::aclass #endif // cpp file 2 void commonclass::method(boost::foo const& x) { ... } // implementation for detail2::aclass Note that the condition used to select the implementation in the header file is not necessarily the same as the one used to decide whether to build the std implementation (the first may be influenced by a user preference, the second is not). Also note that the two implementations are in separate cpp files because linkers have an easier time throwing away entire object files if they're not referenced (at least in static libraries), and may be less good at doing that for individual symbols. And you *don't* make building the second file conditional. If these rules are followed, and as long as the library is compiled with the highest-desired-C++-standard, this allows apps to link against it using either class safely -- you can even have a mix of both in the same app provided those components don't try to directly talk to each other. Actually doing these things in any non-trivial library, however, is *very hard* -- not impossible, if you leverage some preprocessor tricks -- but it's not surprising that most people don't want to do it until they have no other choice. There's also a lot of subtle complications where the compiler doesn't especially help you to catch violations, for things even as simple as private members; pimpl helps but it's still tricky, and has performance tradeoffs. ("aclass" avoids those problems but introduces some of its own.) And it quickly snowballs (as you add more dependencies) into an unmanageable mess, unless you can take a whole slate of dependencies as a fixed unit rather than having them individually configurable. (It's perhaps worth noting that this doesn't *only* apply to compiled libraries; this is similar to how glibc handles the different implementations of std::string between C++03 and C++11, for example.) C++ ABI is *hard*.

Antony Polukhin wrote:

...

My alternative idea of "nice to have" is a single Boost library that can use either boost or std components in its interface. That's not always possible to obtain though.

I've tried that and it kind of works. There are still problems: * users have to use macro to customize the library * bcp still pulls in the Boost alternatives * code redability suffers from typedefs * you still kind of have two different libraries

Here's how it works on Boost.DLL: * users define BOOST_DLL_USE_STD_FS * bcp still puls in Boost.Filesystem, Boost.System... * boost::dll::fs::path = std::conditional_t<a-lot-of-mess> * code in incompatible with the library that was build without BOOST_DLL_USE_STD_FS

That's not what I have in mind. Macros don't solve the problem. What I have in mind is that there is a single library that, in its interface, can seamlessly take either boost::fs::path or std::fs::path, without the user having to define anything. Of course, when building the library, you probably would need to have Boost.Filesystem available.

Alexander Grund wrote:

IMO it would be enough on a cost-benefit ratio to go to C++11 by basically banning the use of MPL in Boost (the single-worst offender on compile times) and reducing the use of type_traits to the absolute minimum. Those 2 are (transitively) in the largest chunk of boost libraries and hence hit hard on compiletimes.

What is the problem with TypeTraits?

On 02/12/2020 15:07, Peter Dimov via Boost wrote:

Alexander Grund wrote:

...

IMO it would be enough on a cost-benefit ratio to go to C++11 by basically banning the use of MPL in Boost (the single-worst offender on compile times) and reducing the use of type_traits to the absolute minimum. Those 2 are (transitively) in the largest chunk of boost libraries and hence hit hard on compiletimes.

What is the problem with TypeTraits?

Boost.TypeTraits was heavily optimized and removed dependency on MPL long time ago. I remember writing to this mailing list complaining about the preprocessed size of type traits and how I was writing my own traits to avoid it. Later TypeTraits contributors did a wonderful job simplifying Boost.TypeTraits and I'm thinking about switching back. The changelog in boost.typeTraits reads: Boost 1.60.0: Refactored traits to depend only on Boost.Config. Greatly simplified code to improve readability and remove workarounds for old compilers no longer supported. Best, Ion

On Wed, Dec 2, 2020 at 9:20 AM Edward Diener via Boost wrote:

On 12/2/2020 4:03 AM, Alexander Grund via Boost wrote:

...

IMO it would be enough on a cost-benefit ratio to go to C++11 by basically banning the use of MPL in Boost (the single-worst offender on compile times) and reducing the use of type_traits to the absolute minimum.

Feel free to offer PRs to those C++98/C++03 libraries to transition them from MPL to mp11 and from Boost type traits to standard type traits so that they can become C++11 libraries.

+1. Nothing is going to be banned, but Alex is encouraged to convince library authors to update their libraries in this way, and encouraged to offer to help them in doing so. Glen On Wed, Dec 2, 2020 at 9:20 AM Edward Diener via Boost wrote:

On 12/2/2020 4:03 AM, Alexander Grund via Boost wrote:

...

...

That's not what I have in mind. Macros don't solve the problem. What I have in mind is that there is a single library that, in its interface, can seamlessly take either boost::fs::path or std::fs::path, without the user having to define anything.

Of course, when building the library, you probably would need to have Boost.Filesystem available.

This may work for simple types like string_view. But it won't work for (non-header-only) libraries using e.g. fs::path. At some point you have to convert to either type or to a third and that is gonna cost you

Additionally that interface may need includes to either or would require the user to include that first introducing an include-order issue.

And finally once you return a type you have no way for "either" (again except for simple types that could on-the-fly convert) and that too requires an explicit choice for the include.

IMO it would be enough on a cost-benefit ratio to go to C++11 by basically banning the use of MPL in Boost (the single-worst offender on compile times) and reducing the use of type_traits to the absolute minimum. Those 2 are (transitively) in the largest chunk of boost libraries and hence hit hard on compiletimes. Then using the std smart-pointers wherever possible would further untangle the libraries. So basically a bottom-up approach to improvement instead of a fork to whatever is the current greatest and latest. This could even be done for/by GSoC, interns or similar. And in ~8 years one can check if C++17 would be a good base point.

Feel free to offer PRs to those C++98/C++03 libraries to transition them from MPL to mp11 and from Boost type traits to standard type traits so that they can become C++11 libraries. I do have the greatest admiration for mp11 so I am not being facetious. But "banning" MPL and Boost type traits is going to currently remove a great number of libraries from Boost. I do agree that a bottom up approach is necessary to transition Boost libraries to C++11 since a given Boost C++98/C++03 library has dependencies on other Boost C++98/C++03 which themselves use the Boost rather than the equivalent standard library.

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

John Maddock wrote:

FYI there are many traits in boost.type_traits which are not part of the standard. I would hate to see folks re-implementing is_detected or has_operator_XXXX just to "not use type_traits".

That, and it's not a heavyweight dependency. I don't know where this impression comes from.

On Wed, Dec 2, 2020 at 11:59 PM Alexander Grund via Boost < boost@lists.boost.org> wrote:

Am 02.12.20 um 19:17 schrieb John Maddock via Boost:

...

FYI there are many traits in boost.type_traits which are not part of the standard. I would hate to see folks re-implementing is_detected or has_operator_XXXX just to "not use type_traits".

I'm aware of that. I didn't say to "ban" type_traits or reimplement it. My suggestion was to "ban" (hard word, I meant to "very strongly discourage using it and actively shift boost libraries away from it") MPL and reduce "the use of type_traits to the absolute minimum". For most (anyone got numbers? I'd say 80% at least) there are std:: counterparts in C++11 which (usually) do the same. And if the library doesn't use any of the additional boost traits, that would remove another dependency and reduce compiletimes for end users (which likely included somewhere already)

From Emil Dotchevski

...

People who want to ban MPL or any other library are effectively admitting they have no skin in the game (they don't use it). We should hear from actual users, but we won't; they don't have a problem to complain about, because we have not broken their code yet.

You might have missed that, but this came up many times in the past. Last I have noticed was https://factorio.com/blog/post/fff-206

I'm not disputing that long build times are a problem, in particular with MPL. My point is that not breaking MPL and libraries that use it has a big upside, and that we can't know how big of an upside that is until we break it, because people don't complain about things that work.

On Wed, Dec 2, 2020 at 6:21 AM Edward Diener via Boost < boost@lists.boost.org> wrote:

Feel free to offer PRs to those C++98/C++03 libraries to transition them from MPL to mp11 and from Boost type traits to standard type traits so that they can become C++11 libraries. I do have the greatest admiration for mp11 so I am not being facetious. But "banning" MPL and Boost type traits is going to currently remove a great number of libraries from Boost. I do agree that a bottom up approach is necessary to transition Boost libraries to C++11 since a given Boost C++98/C++03 library has dependencies on other Boost C++98/C++03 which themselves use the Boost rather than the equivalent standard library.

This is the best approach, but it won't go anywhere because it requires a lot of work and not enough upside (or else it would have been done already). People who want to ban MPL or any other library are effectively admitting they have no skin in the game (they don't use it). We should hear from actual users, but we won't; they don't have a problem to complain about, because we have not broken their code yet. We should keep it that way.

On 3/12/2020 10:34 am, Peter Dimov wrote:

Edward Diener wrote:

...

Feel free to offer PRs to those C++98/C++03 libraries to transition them from MPL to mp11 and from Boost type traits to standard type traits so that they can become C++11 libraries.

Speaking for myself, I would personally never do that (for a library on which others depend) unless and until we (Boost) officially announce that we no longer support C++03.

Wasn't that already announced last year?

On Sat, Nov 28, 2020 at 11:08 AM Peter Dimov via Boost < boost@lists.boost.org> wrote:

Rainer Deyke wrote:

...

From a user perspective, forking is an improvement over the status quo: it means that Boost can guarantee that the 1.x line can stop dropping support for old C++ standards, making it relatively safe to upgrade within the 1.x line.

This is only an improvement in the imaginary world where we have enough resources to maintain two forks. In reality, we have trouble maintaining one.

Why not just alternate releases -- so we'd have a 20 release and then a 17 release, etc? Over time we might change the pattern to emphasize the newer distro as libraries drop support for 17. When c++23 rolls around we can move to there. Note that boost.stacktrace has been voted into c++23 so it might be removed in the future. We'd probably need some branches and testing setup to manage this for libraries that might be in both for some period of time. If we did pull this off, one interesting problem that would be induced is what various linux distros ship with...

On Sun, Nov 29, 2020 at 9:15 AM Peter Dimov via Boost wrote:

Jeff Garland wrote:

...

Why not just alternate releases -- so we'd have a 20 release and then a 17 release, etc?

I have no idea how that's supposed to work.

The point is we wouldn't try to double the number of releases stressing the available resources. For libraries in both releases we would have to have something like release20 and develop20 branches to maintain differences. Libraries only in one of the packages wouldn't have that issue. I'm not claiming this is a fully formed process, but I think something like this could be done.

...

If we did pull this off, one interesting problem that would be induced is what various linux distros ship with...

Linux distros ship Boost built with the default gcc, with the default C++ standard. g++ defaults to C++03 before g++-6, to C++14 before g++-11. A C++17 Boost will be unshippable for a while. C++14 is kind of acceptable today.

Believe g++10 is now c++14 by default and is on Fedora32 -- redhat 8 also has a version available to customers. The other major consumer of pre-C++11 Boost are non-mainstream platforms

such as z/OS, where people are still stuck with C++03.

See e.g.

https://github.com/boostorg/build/issues/534 https://github.com/boostorg/build/issues/535 https://github.com/boostorg/build/issues/519 https://github.com/boostorg/build/issues/511 https://github.com/boostorg/build/issues/473 https://github.com/boostorg/build/issues/471

Thanks. I'm less concerned with supporting them frankly. They have a boost that they can use now -- the rest of us can move on.

On Sun, Nov 29, 2020, 19:14 Peter Dimov via Boost wrote:

Jeff Garland wrote:

...

Why not just alternate releases -- so we'd have a 20 release and then a 17 release, etc?

I have no idea how that's supposed to work.

...

If we did pull this off, one interesting problem that would be induced is what various linux distros ship with...

Linux distros ship Boost built with the default gcc, with the default C++ standard. g++ defaults to C++03 before g++-6, to C++14 before g++-11. A C++17 Boost will be unshippable for a while. C++14 is kind of acceptable today.

GCC moves to c++17 by default https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=0801f419440c14f6772b28f763... AFAIK Clang plans the same move

-----Original Message----- From: Boost On Behalf Of Emil Dotchevski via Boost Sent: 27 November 2020 23:26 To: Boost Cc: Emil Dotchevski Subject: Re: [boost] The new Boost 17.0.0

Deleting support for C++11 and older versions means breaking user code. Therefore, forking means fracturing of the community. I don't see how this is helpful to the users.

Nearly all of Boost is still C++03 compatible - It is only key or core libraries that have this big and bad effect. (People using Boost.Math to calculate a probability will still be able to - nothing much has changed). We have an excellent track record for providing workarounds that keep the old version working where possible, while using macros to allow improvements from using new language features. Eventually library authors run of out road, and/or patience, and say "enough - I need Cxx-more" but it's a slow and continuous process. Our continuous progress but keep as much working as possible strategy has worked very well for decades. The difficulty with our strategy is selling it to potential users who are desperate to be able to tick a box marked 'Cxx-supported'. It gives them a warm feeling, but little in reality. Somehow we don't seem to be able to sell our strategy. But if we get to Boost 17, Boost 20 and Boost 23 will soon follow. Won't more Boost 1 (and then 17, 23...) users be frightened off/confused? Paul PS And KISS applies? (Keep Is Simple Sirs)

On 11/28/2020 11:47 AM, Mike via Boost wrote:

...

Gesendet: Samstag, 28. November 2020 um 13:28 Uhr Von: "Paul A Bristow via Boost"

The difficulty with our strategy is selling it to potential users who are desperate to be able to tick a box marked 'Cxx-supported'. It gives them a warm feeling, but little in reality.

Aren't you dismissing the voiced concerns too easily? I want to be able to interact with libraries using standard library vocabulary types and I don't want my compiletimes to explode when using them. Supporting old c++ standards as many boost libs do can be a problem for both of those goal: - Apparently a lot of the compilation slowdown is due to the use of boost.MPL, which could be replaced in c++11 by mp11 or language constructs.

Proof please about compilation slowdown regarding MPL versus mp11.

- Obviously a c++03 lib can't use std::chrono::duration or std::string_view in its interface. The former can sometimes be added as additional overload if available, however, adding the latter almost certainly leads to ambiguous overload resolution situations. So instead I have to convert the c++11/17/20 types into the appropriate boost types.

I think this is valid. But you are certainly allowed to create a PR for a Boost library which changes its use of a Boost type to its C++ standard library equivalent, with the proviso that the Boost library's base C++ level be C++11 and not C++03. The latter should not be an issue since Boost has already stated that Boost officially supports C++11 on up. Do realize, however, that a number of Boost libraries which have C++11 on up standard library equivalents actually offer more functionality than their C++ standard library equivalent, and that the added functionality may be necessary for some other Boost library.

I'm naming just the two examples that are most relavant to me (I can think of a few more) but the point is: This is not about "having a warm feeling", but about the real costs for users that are a result from the continued support of c++03 and in particular the usage of boost types that have been "merged" into the standard library orthe language.

The difficult part is to place numbers on those costs and especially putting them in relation to the boost user base. It may very well be, that most of the people that are still using boost at all don't use more recent standards or that those costs are insigificantt to them and that the people complaining about the state of boost the loudest don't have any real interest in using boost anyway. Point in case: Almost all projects I'm involved in have removed their boost dependencies if they had any to begin with. So people like me might simply not be a relevant target audience for boost.

Best

Mike

...

PS And KISS applies? (Keep Is Simple Sirs)

There is a lot that can be said about boost but "simple" is certainly not something that comes to mind. Certainly not when we are talking about the implementation and - depending on the lib - not even when considering their usage.

Gesendet: Samstag, 28. November 2020 um 18:32 Uhr Von: "Edward Diener via Boost"

On 11/28/2020 11:47 AM, Mike via Boost wrote:

...

...

Gesendet: Samstag, 28. November 2020 um 13:28 Uhr Von: "Paul A Bristow via Boost"

The difficulty with our strategy is selling it to potential users who are desperate to be able to tick a box marked 'Cxx-supported'. It gives them a warm feeling, but little in reality.

Aren't you dismissing the voiced concerns too easily? I want to be able to interact with libraries using standard library vocabulary types and I don't want my compiletimes to explode when using them. Supporting old c++ standards as many boost libs do can be a problem for both of those goal: - Apparently a lot of the compilation slowdown is due to the use of boost.MPL, which could be replaced in c++11 by mp11 or language constructs.

Proof please about compilation slowdown regarding MPL versus mp11.

Thats what I've heard repeatedly here on the ML and on slack. I see that Peter has supplied a link further up in this thread: http://metaben.ch/ Whether MPL is solely to "blame" for compilation slowdowns people complain about when using boost I don't know, but it stands to reason that the more native language features can be used instead of library based workarounds and the less "redundant" code the compiler has to churn through, the more efficient the code becomes to compile. I've also read that microsofts STL tries to port as much of their code from tag dispatch to if constexpr, because it supposedly inicreases throughput, but I'm not aware of any benchmarks I could compare it with.

...

- Obviously a c++03 lib can't use std::chrono::duration or std::string_view in its interface. The former can sometimes be added as additional overload if available, however, adding the latter almost certainly leads to ambiguous overload resolution situations. So instead I have to convert the c++11/17/20 types into the appropriate boost types.

I think this is valid. But you are certainly allowed to create a PR for a Boost library which changes its use of a Boost type to its C++ standard library equivalent, with the proviso that the Boost library's base C++ level be C++11 and not C++03. The latter should not be an issue since Boost has already stated that Boost officially supports C++11 on up.

Aside from the fact that things like std::stng_view, std::byte or std::memory_resource aren't c++11, but c++17: Could you point me to this statement? All I'm aware of is that there is consensus that boost libs are allowed to drop c++03 support if they want - provided they follow certain procedure. So far I'm aware of 3 libs that are planning to make use of this: Math, Multiprecision and Geometry. I guess there are more, but I didn't get the impression that there is hughe push towards this. Again: I'm not trying to tell anyone what is best for boost or the boost users because I'm lacking expertise, also can't really quantify any of it and am probably not the one who has pay the costs. But there are imho very reasonable reasons why people ask for a version of boost that makes use of c++XX beyond "because it is cool". Best Mike

Jeff Garland wrote:

I can give you a very concrete one -- from_iso_string in date_time. It's signature takes a const std::string&. If I have an std::string_view, then I have to unnecessarily construct a string to call this function -- which harms performance and is ugly.

The answer here is to take a string_view that is constructible from all StringLike types, including std::string_view and boost::string_view. boost::string_view could have been this type, but Marshall refuses to add conversions to it, so everybody needs to roll his own. Or perhaps we need to add one to Core so Marshall's one can be kept pristine and in its original shrink wrap.

Jeff Garland wrote:

...

The answer here is to take a string_view that is constructible from all StringLike types, including std::string_view and boost::string_view.

Sure, but that type is going to need to account for c++17 versus earlier versions.

For this specific use, it doesn't need to. It can just match against a StringLike concept, as I said.

Gavin Lambert wrote:

...

For this specific use, it doesn't need to. It can just match against a StringLike concept, as I said.

Except that you can't use concepts in a compiled library, only in a header-only one. (Or it still requires you to write that concrete type conversion.)

Of course you can. class string_view { public: template > string_view( StringLike const& sl ): p_( sl.data() ), n_( sl.size() ) {} }; void my_compiled_library( string_view sv ); This is not something theoretical. E.g. Victor Zverovich has independently come to the same conclusion: https://twitter.com/vzverovich/status/1333111364357746690

Gavin Lambert wrote:

...

Victor Zverovich has independently come to the same conclusion: https://twitter.com/vzverovich/status/1333111364357746690

I'm not sure if that was the wrong link or if you're referring to something non-obvious to me there, but that doesn't appear related.

You don't see the documentation of fmt::basic_string_view in the screenshot?

On 11/29/20 7:19 PM, Peter Dimov via Boost wrote:

Or perhaps we need to add one to Core so Marshall's one can be kept pristine and in its original shrink wrap.

Please, no yet another string_view. I already have 4 to support in Boost.Log. https://github.com/boostorg/log/blob/a36417bcf34e9818cbc7e013d18c1c83c9e4221...

On 11/29/2020 10:47 AM, Mike via Boost wrote:

...

Gesendet: Samstag, 28. November 2020 um 18:32 Uhr Von: "Edward Diener via Boost"

On 11/28/2020 11:47 AM, Mike via Boost wrote:

...

...

Gesendet: Samstag, 28. November 2020 um 13:28 Uhr Von: "Paul A Bristow via Boost"

The difficulty with our strategy is selling it to potential users who are desperate to be able to tick a box marked 'Cxx-supported'. It gives them a warm feeling, but little in reality.

Aren't you dismissing the voiced concerns too easily? I want to be able to interact with libraries using standard library vocabulary types and I don't want my compiletimes to explode when using them. Supporting old c++ standards as many boost libs do can be a problem for both of those goal: - Apparently a lot of the compilation slowdown is due to the use of boost.MPL, which could be replaced in c++11 by mp11 or language constructs.

Proof please about compilation slowdown regarding MPL versus mp11.

Thats what I've heard repeatedly here on the ML and on slack. I see that Peter has supplied a link further up in this thread: http://metaben.ch/

Whether MPL is solely to "blame" for compilation slowdowns people complain about when using boost I don't know, but it stands to reason that the more native language features can be used instead of library based workarounds and the less "redundant" code the compiler has to churn through, the more efficient the code becomes to compile. I've also read that microsofts STL tries to port as much of their code from tag dispatch to if constexpr, because it supposedly inicreases throughput, but I'm not aware of any benchmarks I could compare it with.

...

...

- Obviously a c++03 lib can't use std::chrono::duration or std::string_view in its interface. The former can sometimes be added as additional overload if available, however, adding the latter almost certainly leads to ambiguous overload resolution situations. So instead I have to convert the c++11/17/20 types into the appropriate boost types.

I think this is valid. But you are certainly allowed to create a PR for a Boost library which changes its use of a Boost type to its C++ standard library equivalent, with the proviso that the Boost library's base C++ level be C++11 and not C++03. The latter should not be an issue since Boost has already stated that Boost officially supports C++11 on up.

Aside from the fact that things like std::stng_view, std::byte or std::memory_resource aren't c++11, but c++17: Could you point me to this statement?

What statement ? Boost doesn't officially support C++03, even if individual libraries still support C++03, so a PR that changes a library that currently supports C++03 as its base level to instead support C++11 as its base level by using C++11 standard libraries in its code instead of the Boost equivalent libraries, would not be a radical change. Of course it is still up to the maintainer(s) of the library to accept the PR. As for changing a library's base level to C++14, C++17, or C++20 via a PR that probably needs to be justified since it would remove that library's usefulness for those compiling at the C++11 level.

All I'm aware of is that there is consensus that boost libs are allowed to drop c++03 support if they want - provided they follow certain procedure. So far I'm aware of 3 libs that are planning to make use of this: Math, Multiprecision and Geometry. I guess there are more, but I didn't get the impression that there is hughe push towards this.

Again: I'm not trying to tell anyone what is best for boost or the boost users because I'm lacking expertise, also can't really quantify any of it and am probably not the one who has pay the costs. But there are imho very reasonable reasons why people ask for a version of boost that makes use of c++XX beyond "because it is cool".

On Sun, Nov 29, 2020 at 2:04 PM Glen Fernandes via Boost < boost@lists.boost.org> wrote:

Note that for new libraries being accepted into Boost, the only requirement is that (at the time of review) they compile with at least two C++ compilers and that they at least compile under the current C++ standard (which today is C++17).

i.e. We accept new libraries that don't compile under C++11, and we even have some libraries today that require C++14 or higher.

New libraries always try to support the oldest C++ standard possible. When your library is new, you instinctively grasp that it will be more popular the wider the range of the supported platforms. The flip side is that a few years later, that oldest C++ standard supported by the library is older still, yet the user base is bigger because of it. Don't turn it into a trap now, keep it working.

Gesendet: Sonntag, 29. November 2020 um 22:43 Uhr Von: "Edward Diener via Boost"

On 11/29/2020 10:47 AM, Mike via Boost wrote:

...

...

Gesendet: Samstag, 28. November 2020 um 18:32 Uhr Von: "Edward Diener via Boost"

On 11/28/2020 11:47 AM, Mike via Boost wrote:

...

[...]

...

...

- Obviously a c++03 lib can't use std::chrono::duration or std::string_view in its interface. The former can sometimes be added as additional overload if available, however, adding the latter almost certainly leads to ambiguous overload resolution situations. So instead I have to convert the c++11/17/20 types into the appropriate boost types.

I think this is valid. But you are certainly allowed to create a PR for a Boost library which changes its use of a Boost type to its C++ standard library equivalent, with the proviso that the Boost library's base C++ level be C++11 and not C++03. The latter should not be an issue since Boost has already stated that Boost officially supports C++11 on up.

[...] Could you point me to this statement?

What statement ?

Whatever you meant when you wrote:

since Boost has already stated that Boost officially supports C++11 on up.

On Sun, Nov 29, 2020 at 6:41 PM Edward Diener wrote:

On 11/29/2020 6:10 PM, Mike via Boost wrote:

...

...

Gesendet: Sonntag, 29. November 2020 um 22:43 Uhr Von: "Edward Diener via Boost"

On 11/29/2020 10:47 AM, Mike via Boost wrote:

...

...

Gesendet: Samstag, 28. November 2020 um 18:32 Uhr Von: "Edward Diener via Boost"

On 11/28/2020 11:47 AM, Mike via Boost wrote:

...

...

...

...

- Obviously a c++03 lib can't use std::chrono::duration or std::string_view in its interface. The former can sometimes be added as additional overload if available, however, adding the latter almost certainly leads to ambiguous overload resolution situations. So instead I have to convert the c++11/17/20 types into the appropriate boost types.

I think this is valid. But you are certainly allowed to create a PR for a Boost library which changes its use of a Boost type to its C++ standard library equivalent, with the proviso that the Boost library's base C++ level be C++11 and not C++03. The latter should not be an issue since Boost has already stated that Boost officially supports C++11 on up.

[...] Could you point me to this statement?

What statement ?

Whatever you meant when you wrote:

...

since Boost has already stated that Boost officially supports C++11 on up.

I recall something Peter Dimov wrote about Boost no longer guaranteeing support of code compiled at the C++03 level, but do not remember where it is on the website.

It's not an official statement and it's not on the Boost website. It was a proposal, and hosted on Peter's github: https://pdimov.github.io/articles/phasing_out_cxx03.html Glen

On Sat, Nov 28, 2020 at 5:20 AM Paul A Bristow via Boost < boost@lists.boost.org> wrote:

But if we get to Boost 17, Boost 20 and Boost 23 will soon follow. Won't more Boost 1 (and then 17, 23...) users be frightened off/confused?

Hello, in our code base we use Boost, Boost 17 and Boost 23. When I try to ...... I get a core dump. Please help!

On 29.11.20 22:32, Edward Diener via Boost wrote:

On 11/29/2020 2:14 PM, Raffi Enficiaud via Boost wrote:

...

On 27.11.20 09:58, Antony Polukhin via Boost wrote: [...]

Boost.Preprocessor works in whatever C++ level you want. It has no reliance on any C++ standard or Boost equivalent library, or any other Boost library. That does not mean  you could not eliminate use of its macros in code if you have a better alternative.

My point is that the biggest blocker for larger adoption of Boost.Test is the size of monolithic Boost, not C++17 (which it supports). Boost.Test depends on various libs among which preprocessor. It is good design in a single library to reuse functions. But * Boost.Test is not shipping some additional feature on top of preprocessor, it is a client of it. Preprocessor is an implementation detail of Boost.Test. * Boost is not a single library (especially since "modular Boost"), it is an umbrella of libraries. Each library is addressing a specific need in the C++ world and has a specific target audience. Code reuse should be thought as a way to bring features faster to market, this is a price usually customer is ok to pay for. But then library coupling has various downsides, such as slowing wider adoption and harming retention. Preprocessor is a valuable library (especially now that I am trying to re-implement a tiny subset of it) but that dependency has to be put in the light of what it costs to customers, and the customers of boost.test and preprocessor have little overlap.

On Tue, Dec 1, 2020 at 3:27 PM Antony Polukhin wrote:

Exactly that's the problem I'm trying to solve with the Boost17. The problem becomes much bigger, when the Boost library becomes part of the iterface. For example, Boost.DLL needs shared_ptr and filesystem in it's interface. Users suffer from boost::filesystem and boost::shared_ptr if their projects use C++17 std:: alternatives.

Why haven't you solved it for Boost.DLL users by switching to std::shared_ptr and std::filesystem yet? You don't need anyone's permission. Glen

On Tue, Dec 1, 2020 at 4:16 PM Antony Polukhin wrote:

On Tue, Dec 1, 2020, 23:36 Glen Fernandes wrote:

...

On Tue, Dec 1, 2020 at 3:27 PM Antony Polukhin wrote:

...

Exactly that's the problem I'm trying to solve with the Boost17. The problem becomes much bigger, when the Boost library becomes part of the iterface. For example, Boost.DLL needs shared_ptr and filesystem in it's interface. Users suffer from boost::filesystem and boost::shared_ptr if their projects use C++17 std:: alternatives.

Why haven't you solved it for Boost.DLL users by switching to std::shared_ptr and std::filesystem yet? You don't need anyone's permission.

Because I'm not planning to drop support for the pre-C++17 users. I wish to provide another library for users that avoid existing Boost.DLL because of the dependencies.

Wich brings me to a less radical idea: we may simplify acceptance of dependenceless library clones. Next step would be to provide predefined bcp'ed subsets of libraries (boost 17, boost 23?)

One option is for that other library (DLL for C++17+) to still live under the boostorg/dll repository - i.e. it doesn't need to have its own repository. If so, there's no concern about acceptance either since you already have it (you can maintain both under boostorg/dll and then eventually choose to drop the C++03 variation in a later Boost release etc...). Glen

On Tue, Dec 1, 2020 at 4:46 PM Antony Polukhin wrote:

On Wed, Dec 2, 2020, 00:23 Glen Fernandes wrote:

...

On Tue, Dec 1, 2020 at 4:16 PM Antony Polukhin.

...

Wich brings me to a less radical idea: we may simplify acceptance of dependenceless library clones. Next step would be to provide predefined bcp'ed subsets of libraries (boost 17, boost 23?)

One option is for that other library (DLL for C++17+) to still live under the boostorg/dll repository - i.e. it doesn't need to have its own repository.

You mean folder structure like include/boost/dll/ include/boost/dll17/

Would the bcp treat dependencies of include/boost/dll17 separately from include/boost/dll?

Yes, i.e. if we establish some convention like that, then the tools should understand that. This gives people much more freedom than have to have up to M*n repositories (for n Boost libraries, and M different minimum-supported standards) and especially have to go through an additional (M-1) formal reviews for what is really the same library just switching boost:: components to std:: ones. Glen

Gesendet: Mittwoch, 02. Dezember 2020 um 11:18 Uhr Von: "Andrey Semashev via Boost"

On 12/2/20 12:43 AM, Antony Polukhin via Boost wrote:

...

On Wed, Dec 2, 2020, 00:23 Glen Fernandes wrote:

...

On Tue, Dec 1, 2020 at 4:16 PM Antony Polukhin.

...

Wich brings me to a less radical idea: we may simplify acceptance of

dependenceless library clones. Next step would be to provide predefined bcp'ed subsets of libraries (boost 17, boost 23?)

One option is for that other library (DLL for C++17+) to still live under the boostorg/dll repository - i.e. it doesn't need to have its own repository.

You mean folder structure like include/boost/dll/ include/boost/dll17/

Would the bcp treat dependencies of include/boost/dll17 separately from include/boost/dll?

AFAIR, bcp operates on file level, so yes, it should be able to select individual headers used by some root source file, regardless of git submodules.

I believe this is true for the header files, but how would bcp know which subset of source files to include? Regards Mike

...

I believe this is true for the header files, but how would bcp know which subset of source files to include?

bcp gives you the header files included into a source file, and nothing more. It also has the caveat that it doesn't preprocess files, so it may miss includes that are obscured by macros. It does not give you the source files for separately compiled libraries, which may be required to implement components declared in those headers.

It does give you source files - specifically everything in libs/libname/src when it finds a header from "libname". John. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

On 12/1/2020 4:03 PM, Robert Ramey via Boost wrote:

On 12/1/20 12:23 PM, Antony Polukhin via Boost wrote:

...

On Mon, Nov 30, 2020, 04:19 Raffi Enficiaud via Boost

...

when the Boost library becomes part of the iterface. For example, Boost.DLL needs shared_ptr and filesystem in it's interface. Users suffer from boost::filesystem and boost::shared_ptr if their projects use C++17 std:: alternatives.

I'm kind of intrigued with the idea of including things like shared_ptr (and others) in a (user) library API.  I never do this.  In general, I never use mutable references to mutable objects in any API.  That is I always pass f(const T &).  So I never have to pass ownership to a user function.  So I can pass a reference to some constant underlying type.

You may still have to choose the type between Boost and a C++ standard alternative and no matter which type you choose the end-user may be using the other type in his code and be irritated that you are not using the type he is using.

For example rather than

unsigned int string_hash( const std::string s &) {...}

I would use

unsigned int string_hash( const std::string s &) const {     return string_hash( s.c_str() ); }

Of course making this change after the fact would be quite a bit of work.  But since I do it from the beginning, it's no extra work at all.  And it eliminates many, many problems including the one described above. It's gotten to the point that for me, non constant parameters parameters are code smell.  I almost never use them. And when I do, usage is almost always confined to member functions.

I'm aware that this is actually off topic so sorry for hijaking the thread.  But I believe that a lot of this (and other discussions), rather than trying to address problems with reconciling boost and std libraries would (mostly disappear) if users would step back and think more about what functional program can mean in the real world.