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/