Boost logo

Boost :

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

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?

Boost list run by bdawes at, gregod at, cpdaniel at, john at