Re: [Boost-users] Boost or Standard when there is the choice?

Subject: Re: [Boost-users] Boost or Standard when there is the choice?
From: Ahmed Charles (acharles_at_[hidden])
Date: 2014-02-12 12:30:17

From: s_sourceforge_at_[hidden]
To: boost-users_at_[hidden]
Date: Tue, 11 Feb 2014 20:08:59 +0000
Subject: Re: [Boost-users] Boost or Standard when there is the choice?
> A standard library implementation is /probably/ more stable, better 
> tested and more micro-optimised than Boost *eventually*. I stress the 
> eventually - right now, C++ 11 standard libraries are still getting 
> the bugs wringed out of them. but they are settling down and in the 
> past year certainly I've found bugs more frequently in Boost 
> implementations of C++11 features than in say Dinkumware's STL.

> Regarding the micro optimisation remark, I make this purely based on 
> my experience with Visual Studio where the Dinkumware implementation 
> almost always outperforms or is similar to a Boost implementation, 
> especially in VS2013. This is partially because a Boost 
> implementation usually has a lot more features and therefore a larger 
> code footprint, but it's also because Dinkumware do a lot of micro 
> optimisation once code is known stable.

Since I'm pedantic, I think there's a phenomenon here that you're
seeing but not ascribing properly. Dinkumware's initial implementation
tends to not have much concern for performance at all and Boost's solution
tends to be more mature by the time it's standardized and gets implemented
by Dinkumware, which usually results in Boost being faster. The reason
that Microsoft's STL ends up performing better than both Dinkumware's
and Boost's implementations is because Microsoft cares about performance
and implements most of the optimizations and because, like you said,
Boost has more surface area. Microsoft currently cares and they know
their compiler/platform better.

Note: the STL that Dinkumware ships is not the same as the one Microsoft
ships, so perhaps I'm just being pedantic about naming.

As an example, Dinkumware's STL didn't have the make_shared optimization
that Boost implemented until Microsoft rewrote make_shared to include it.
That's a case where Boost did better until the standard provider improved
their implementation. Granted, I don't think shared_ptr is complex enough
that there is any difference between optimal implementations.

PS. This ignores optional parts of the standard like advanced math functions
which Boost provides but most standard library vendors will not, or if
they do, it will only be to get the 'complete implementation' rubber stamp.

> Lastly, using STL implementations is probably more future proof over 
> say the next twenty years than using Boost. I can certainly see that 
> once C++11 is ubiquitous, the incentive to maintain Boost C++11 
> implementations of standard features will drop substantially. Future 
> users of your code base will then have to port over code away from 
> Boost to gain timely access to fixes.
 
> All that said, I still choose Boost.Thread primitives over STL 
> primitives, mainly due to the much superior feature set and I know 
> many of those superior features will end up in C++1y, so why wait 
> till then? Note that I use the namespace mapping technique to map 
> /some/ implementation into a private namespace, that makes switching 
> to a STL implementation later fairly trivial.