Re: [boost] [threads] Launch deferred for async

Subject: Re: [boost] [threads] Launch deferred for async
From: Gavin Lambert (boost_at_[hidden])
Date: 2018-11-28 00:03:08

On 27/11/2018 23:25, Stephan Menzel wrote:
>> Ah, this explains it. I have BOOST_THREAD_VERSION 3 explicitly defined
>> because I couldn't be having with some of the version 4 behavior. Which is
>> why I prefer boost threads over std threads in the first place.
>>
>> Thanks for the heads up. I will try to re-evaluate if I should go for
>> version 4 after all but as I recall there were some strong reasons not to
>> do it. At least now I know what I'm trading in for that.

Sometimes you can enable specific sub-features of a new version while 
mostly using the old version, but combinations are probably less well 
tested and I would assume there are probably hidden dependencies.

> 1)  When using version 4, boost::future<> doesn't exist. I have to use
> boost::unique_future<> instead, which is nowhere mentioned in the docs. So
> essentially, when I do the examples in the docs, I have to force the
> version to 3 or lower or it won't compile. Unless I use shared_future that
> is.

It should be the other way around -- version 2 (the default) uses 
unique_future<> while version 3 and 4 use future<>.

https://www.boost.org/doc/libs/1_68_0/doc/html/thread/build.html#thread.build.configuration.future

It was renamed due to alignment with the C++11 standard.  Alias 
templates would have been nice, but I guess Boost.Thread is mostly 
targeted at C++03 and those aren't available there anyway.

> 2) I have several occurrences of using boost::static_visitor for treating
> variants. And I often move the value into there. Like this:
> 
>      boost::apply_visitor(my_visitor, std::move(value));

I don't think I can help with that one, at least not without more 
context. :)

Maybe the rest of the info on that page might help, since it appears you 
missed it?