|
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]>
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.
>
>
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
is.
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.
Cheers,
Stephan
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk