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?