Oswin Krause wrote:
What severe interoperability issues?
Interoperability issues between code that is designed using the std:: versions and code using the boost libraries. Starting with: mixing boost and std libraries as it was intended to be. boost::shared_ptr is an example that one can get to work [1],
Yes, see http://www.boost.org/doc/libs/1_63_0/libs/smart_ptr/sp_techniques.html#anoth...
however it is not straight forward(look at all the slightly wrong code out there) and requires sacrifices in performance. Most other libraries are harder and the situation is often even undefined. For example, I have no idea what will happen when I use std::this_thread inside a thread started by boost::thread.
This specific case should work; even though the standard doesn't say what will happen if you use it in threads not started by std::thread, all implementations ought to support OS threads started by pthread_create or CreateThread as well. Doesn't matter if Boost.Thread is used.
Thus it is hard for me to write code that is agnostic to the threading library used. However, if i settle for boost::thread i also have to use boost::chrono. I could use preprocessor macros, but if I have to deliver a library, I have to make a hard decision.
This is a real problem, but your desire
I sometimes wish those libraries got never adopted for this reason.
is baffling. You do know that boost::shared_ptr predates std::shared_ptr by many years (the page above is from 2003) and is in fact the reason there is std::shared_ptr? That we made std::shared_ptr happen? How on Earth not adopting it would have made things better?