Re: [boost] [partly OT] Re: [review queue] What to do about the library review queue?

Subject: Re: [boost] [partly OT] Re: [review queue] What to do about the library review queue?
From: Peter Dimov (lists_at_[hidden])
Date: 2017-03-16 18:22:23

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#another_sp

> 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?