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

Subject: Re: [Boost-users] Boost or Standard when there is the choice?
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-02-13 14:35:24

On 13 Feb 2014 at 7:24, Stephan T. Lavavej wrote:

> Since then, it has been explained to me that Boost paid the cost of an
> extra pointer as make_shared was implemented "non-intrusively", while
> libstdc++ accidentally paid an extra pointer (not noticing the control
> block redundancy). I don't know when Boost implemented the optimization,
> and whether libstdc++ has yet, but they are both aware, and I hope
> libc++ is too (I should ask Marshall/Howard). 

Firstly Stephan this is a hugeful useful post, and thank you for 
taking the time to write it. The subject of whether to use STL or 
Boost implementations of C++11 facilities is likely to come up again 
and again, and unlike most speculators including myself, you actually 
know the answer.

I will mention with regard to the above that the non-intrusiveness of 
Boost implementations is - as you acknowledged - done deliberately. 
This can make maintenance in the face of refactors easier to grok, 
something important for an open source project on which most work, 
especially in recent years, is done outside a for-pay context. In 
comparison any of the major STLs is vastly better resourced than 
Boost, one of the big reasons Boost had to bring in a community 
maintenance programme.

As you know, there are some big enhancements of the C++ threading 
primitives planned to come soon to Boost with the expectation that 
they provide a testing ground for C++-1y directions, as some of the 
papers which have gone before WG21 recently have been ... perhaps 
insufficiently ambitious and overly ambitious simultaneously. 
Certainly I think everyone here can see a metaprogrammed reusable 
monadic framework implementing continuations as very desirable - that 
way Boost.Thread's facilities and Boost.AFIO's facilities plus 
several other Boost libraries can all reuse the same continuations 
metaprogramming rather than going it alone individually. We're hoping 
for a really great student for this year's GSoC to help drive forth 
that generic framework.

> [Niall]
> > (i) how close is vanilla Dinkumware to the STL shipped in VS2013
> 
> I am unable to answer this question, as I have never seen Dinkumware's
> vanilla library. 
>
> I can tell you that we work closely with Dinkumware, and that (in 2010
> and above) what may appear to be Microsoft-specific edits, have actually
> been sent upstream to Dinkumware's master sources, which are capable of
> generating drops for Microsoft or other clients (whose existence, but
> not identity, I am aware of). Between 2005 and 2010 the sources were
> divergent, which caused difficulty in picking up new features (starting
> with TR1). Now we can rapidly acquire new features. 

I suspected that exact case simply through comparing the BB10 NDK and 
VS2013. The NDK's STL seemed to have a lot of Microsoft formatted 
code (it looks distinctive somehow, I can't quite explain how).

> > (ii) would you, Stephan, say that the VS2013 STL is likely to be on average
> > better performance than a Boost implementation of some given C++ 11 feature,
>
> It varies. Some regexes we do better, some we do worse (e.g. many
> alternations).

The <random> generator implementations on ARM in libstdc++ are a good 
example of being pathologically awful performance.

> "non-intrusive". Our shared_ptr on ARM is likely to be better than
> Boost, since we go to the trouble of using weaker-than-SC atomics. Our
> <atomic> is probably better on 2013 since we've figured out how to use
> intrinsics for almost everything (and even better in the next major
> version), although maybe not if you've looked at our intrinsics
> carefully too. Our threading stuff, we've tried to be fast by powering
> our futures with ConcRT, but I also know where a few bodies are buried
> (e.g. call_once). 

One GSoC project proposal I added is to patch in memory transaction 
support throughout Boost wherever it makes sense. We have an 
implementation (which I wrote), we just need someone to do the donkey 
work of the refactor.

It still doesn't gain us the automatic use of cooperative scheduling 
thanks to ConcRT, but it should help.

> Correctness-wise is another story (e.g. I need to rewrite <functional>,
> Boost.Bind is more solid), although I will say that for the type traits,
> VC is likely to give more correct answers because I can request compiler
> hooks as I need them (and more importantly, compiler fixes). 

I am surprised ... I had less issues getting std::bind() to work 
mostly as expected across all compilers as compared to Boost.Bind 
which has a particular knack of breaking at least one particular 
compiler and none of the others (it ICEs VS2010 when used with C++11 
very frequently in particular). In my particular use case scenarios 
only of course, others almost certainly have a better experience.

Thanks Stephan.

Niall

-- 
Currently unemployed and looking for work in Ireland.
Work Portfolio: http://careers.stackoverflow.com/nialldouglas/