On Thu, May 21, 2015 at 3:53 PM, Niall Douglas
On 18 May 2015 at 21:12, Andrey Semashev wrote:
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.
All that doesn't make Boost obsolete, which is how Niall phrased it.
I think a majority of Boost users, rather than developers, will disagree. I worked recently on a C++ 11 code base which had mixed boost::future and std::future due to no better choice available. It was a royal pain in the ass to deal with (lots of std::async usage to work around the incommensurability).
Having a mixture of similar STL and Boost components certainly complicates life. However when it comes to a choice between STL and Boost the choice it not quite clear. And much more often than not there simply isn't a choice because STL doesn't have an equivalent.
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.
This is *exactly* the point. It tests your code's assumptions about how a STL implementation works and forces you to refactor those assumptions.
No, I was more talking about bugs and inefficiency. For example, I had some code which crashed the compiler when I used std::bind but compiled well with boost::bind or phoenix::bind. Also, a while ago I tested performance of different regex implementations (IIRC, libc++, Dinkumware, Boost.Regex, Boost.Xpressive) and Boost.Regex turned out to be significantly faster than the rest on my patterns. There are most probably counter examples too, the point is that you should not expect porting to STL to be always beneficial - it may very well be the opposite.
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.
You are arguing in favour of a monoculture.
I'm just saying there are practical reasons to choose Boost over STL.