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.buil... 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?