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
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
Maybe the rest of the info on that page might help, since it appears you
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk