Boost logo

Boost Users :

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.


Currently unemployed and looking for work in Ireland.
Work Portfolio:

Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at