Re: The new Boost 17.0.0

From: Glen Fernandes (glen.fernandes_at_[hidden])
Date: 2020-12-02 14:28:00

On Wed, Dec 2, 2020 at 9:20 AM Edward Diener via Boost
<boost_at_[hidden]> 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
<boost_at_[hidden]> 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