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-18 14:12:07

On Monday 18 May 2015 20:36:55 Peter Dimov wrote:
> Paul A. Bristow wrote:
> > > It feels like either of us is living in a parallel universe, really.
> > 
> > +1 - and I'm not in the Douglas one either :-(
> > 
> > Compiler and language changes are continuous, not strictly quantizable,
> > and so Boost must continue to track changes as is has from the start.  C++
> > 11/14 will be followed by C++17 and C++2z ...
> 
> 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.
> 
> In the pre-Douglas universe, you (the library author) had to rely on their
> Boost implementation, which coupled you to other Boost components, sometimes
> to their specific versions.
> 
> In the Douglas universe, you can use the standard library for all that,
> allowing your library to be independent of the rest of Boost.
> 
> Even if you use, say, boost::shared_ptr on C++03 compilers, since your
> library uses the interface of std::shared_ptr on C++11, this is a certain
> guarantee that it does not depend on anything specific to a particular
> version of boost::shared_ptr. As long as boost::shared_ptr is standard
> conforming, any version ought to do and upgrading boost::shared_ptr ought to
> not break things.
> 
> Hence the idea that libraries can follow their own release schedules.

All that doesn't make Boost obsolete, which is how Niall phrased it.

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. 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. It 
reminds me of the days when STLport was active - I would often use it instead 
of the compiler-supplied STL on all platforms for the same reasons.