Re: [scope] Scope review starts on November 26th

From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2023-11-28 18:41:04

niedz., 26 lis 2023 o 04:27 Vinnie Falco via Boost <boost_at_[hidden]>
napisał(a):

> On Sat, Nov 25, 2023 at 6:17 PM Andrey Semashev via Boost
> <boost_at_[hidden]> wrote:
> > I think there's little point in introducing new libraries that are
> > predetermined to be locked down to be strictly equivalent to the
> > standard C++ components.
>
> Au contraire, mon ami; A Boost library which is "merely" strictly
> equivalent to its std counterpart offers one significant quantum of
> value: it can be used in versions of C++ which are older than the
> standard in which the std component was introduced.
>
> > The fact that some Boost libraries that now have standard counterparts
> > have certain extensions is a good thing because it offers users a choice
> > and provides them the functionality they need.
>
> This might have been a convincing argument five years ago, but
> empirical evidence disproves this claim. No one is intentionally
> choosing Boost's error_code, filesystem, or thread over the std
> equivalent because of "the functionality they need."
>
> The reality is that people end up using the boost equivalent
> components because they are forced to. Either because an upstream
> library requires it, such as Asio, or because it is already in the
> existing code base. Users have clearly indicated that they vastly
> prefer the std component over the Boost one regardless of whether the
> boost component offers additional value.
>
> The only time the boost component is preferred, is when the additional
> functionality is so significant in the value that it brings, that it
> justifies the additional friction required to integrate the component.
> One example that comes to mind is Boost.Variant2.
>
> New features added to std-flavored boost components become incredibly
> annoying years later when a project wants to switch back to the std
> equivalent, perhaps because they were finally able to upgrade to the
> latest C++. They discover they have to perform a non-trivial
> refactoring of the code base because over time these additional
> features that we added end up getting relied upon and cannot be
> extricated easily.
>
> Every time I try to talk people into using Boost this issue of boost
> having copies of std components comes up and not in a positive way. In
> fact, I think from now on I will write a very short review which
> encourages to REJECT any proposed library which clones std components
> and adds or changes anything, unless the feature or modification is so
> incredible that it "walks on water." I look forward to seeing whether
> these vaunted Boost.Scope "additions" meet this criteria.
>
> > The fact that the standard doesn't provide that functionality (provided
> that it is needed by users) is a deficiency of the standard, not the Boost
> library.
>
> Users vastly prefer even the "defective" std components over the
> theoretically-better boost components, simply by virtue of them being
> in the standard, with all of the benefits this brings. Education,
> documentation, ubiquity, and so on, for std components is orders of
> magnitude more robust than the boost equivalent. This more than makes
> up for any perceived deficiencies. Like it or not, vocabulary types
> and algorithms which make it into std are going to have an enormous
> advantage over any third party code.
>

Maybe this argument applies with different weight for vocabulary and
non-vocabulary types.

My understanding of a vocabulary type is that it is one that you would
likely expose in your interfaces, and have two (or more) libraries
communicate via it.
optional, shared_ptr, variant, error_code are types of this sort. For those
types you would strongly prefer to use the std version, because it is
likely that other 3rd party libraries will also use the std version.

scope_guard is a type you will use internally in your implementation, so
whether you pick the Boost version or the std version is your private
business.

Regards,
&rzej;

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