Boost logo

Boost :

Subject: Re: [boost] [threads] Launch deferred for async
From: Stephan Menzel (stephan.menzel_at_[hidden])
Date: 2018-11-27 10:25:39

On Tue, Nov 27, 2018 at 7:24 AM Stephan Menzel <stephan.menzel_at_[hidden]>

> 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.
A little update in case anyone is interested. First of all, going to
version 4 does indeed fix the problem. As to the reasons why I went to
version 3 I have some curious findings.

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

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));

Being seemingly unrelated to boost threads, this won't compile anymore when
I remove threads version 3. I had to remove the std::move() operator. I
have no idea why but the error novel suggests it's got something to do with
boost units being somewhere in the include path. I do use boost units but
nowhere near that apply visitor lines.

I can live with both of these things but they appear very strange to me.


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