Re: [boost] Some statistics about the C++ 11/14 mandatoryBoost libraries

Subject: Re: [boost] Some statistics about the C++ 11/14 mandatoryBoost libraries
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2015-05-21 09:41:31

On Thu, May 21, 2015 at 3:53 PM, Niall Douglas
<s_sourceforge_at_[hidden]> wrote:
> On 18 May 2015 at 21:12, Andrey Semashev wrote:
>
>> > The defining characteristic of the Douglas universe is that the standard
>> > library now contains the many essential components (tuple, shared_ptr,
>> > function, bind, type traits, threads, atomics, and so on) that were
>> > previously only supplied by Boost.
>>
>> All that doesn't make Boost obsolete, which is how Niall phrased it.
>
> I think a majority of Boost users, rather than developers, will
> disagree. I worked recently on a C++ 11 code base which had mixed
> boost::future and std::future due to no better choice available. It
> was a royal pain in the ass to deal with (lots of std::async usage to
> work around the incommensurability).

Having a mixture of similar STL and Boost components certainly
complicates life. However when it comes to a choice between STL and
Boost the choice it not quite clear. And much more often than not
there simply isn't a choice because STL doesn't have an equivalent.

>> Even for components that are in STL11, I'm still cautious about porting my
>> code from Boost to STL11 because different implementations have different
>> quality and because of that the code breaks or performance suffers.
>
> This is *exactly* the point. It tests your code's assumptions about
> how a STL implementation works and forces you to refactor those
> assumptions.

No, I was more talking about bugs and inefficiency. For example, I had
some code which crashed the compiler when I used std::bind but
compiled well with boost::bind or phoenix::bind. Also, a while ago I
tested performance of different regex implementations (IIRC, libc++,
Dinkumware, Boost.Regex, Boost.Xpressive) and Boost.Regex turned out
to be significantly faster than the rest on my patterns. There are
most probably counter examples too, the point is that you should not
expect porting to STL to be always beneficial - it may very well be
the opposite.

>> Of course,
>> most of the time the transition goes smoothly and most issues can be worked
>> around, but nevertheless in portable code Boost is still preferable.
>
> You are arguing in favour of a monoculture.

I'm just saying there are practical reasons to choose Boost over STL.