On Tue, Nov 27, 2018 at 7:24 AM Stephan Menzel
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