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: Oswin Krause (Oswin.Krause_at_[hidden])
Date: 2017-03-16 19:00:02

On 2017-03-16 19:22, Peter Dimov via Boost wrote:
> 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

Yes, but as far as i can see, this can impact performance. I see no way 
to implement this without allocating additional storage. S it acts 
reasonable, but far from nice.

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

The documentation does not say so. This is the issue.
> 
>> 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?

I do know that. I have learned C++ 15 years ago, when shared_ptr was the 
new sh*t in town, so to speak.
At that time, more often than not, boost used to play nice with the 
standard library:
you could expect that all std algorithms would work with boost 
containers and all boost algorithms
would work with std containers. And newcomers were told: prefer std and 
sprinkle some boost in between when necessary.
This worked well over so many years and made boost to such an important 
cornerstone as the "inofficial c++ standard library".

This changed with the adoption of some boost libraries into the 
standard. The rule: "work nice with std"
was suddenly hard to fullfil and those boost libraries, honestly, look a 
bit out of place by now. Sometimes it feels
like the boost and std are competing libraries and the boost version is 
not even acknowledging the existence of the std version let
alone trying to play nice with it.

So the c++ landscape got more complicated, not simpler by including the 
most successful libraries of boost. This is a tough sell.