
On 5 Nov 2013 at 19:42, Gavin Lambert wrote:
A while back there was a discussion in my team whether (now that the current release of applications are being built in a C++11 compiler) the code should continue to use boost::shared_ptr as before, or mix in std::shared_ptr in newer code, or do a global search-n-replace. (And similarly for some of the threading stuff.)
Mixing was quickly ruled out as too confusing and painful (due to incompatibilities). And we eventually decided not to search-n-replace because (a) the two implementations are not entirely identical, so this might introduce bugs; (b) continuing to use the Boost version makes it easier to backport changes to older releases that still use C++98 compilers; (c) presumably the Boost version would be bugfixed or feature-enhanced in advance of the std version, or internally fall back to the std version where compatible.
Do you think that some of those assumptions are flawed?
At my last employer before I was let go, we seriously investigated having a clang AST parser find instances of Boost use and replace them with C++11 STL use instead. In fact, boost::shared_ptr<> => std::shared_ptr<> was exactly the test case I was developing against. We were aiming to remove the many duplicate copies of Boost we were shipping which was unnecessary because most of them were being using in lieu of C++11. If in your case you're happy with the Boost implementation, and you'd be importing Boost anyway because you're using parts the C++11 STL doesn't provide, I'd just stick with Boost. Not changing code = not introducing new bugs. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/