On 16 Jan 2015 at 18:07, Gavin Lambert wrote:
1. They tie your code into "future islands" which are fundamentally incommensurate with all code which doesn't use the same future as your code. Try mixing code using boost::future and std::future for example, it's a nightmare of too easy to be racy and unmaintainable mess code. If Compute provided a boost::compute::future, it would yet another new future island, and I'm not sure that's wise design.
Is there somewhere I can read up some more on this issue?
I can't think of anywhere except this thread really. I guess anyone who has tried mashing together different types of futures knows what a future island is immediately.
Perhaps I have not put enough thought into it, but it seems like it should be trivial to create a wrapper to convert a std::future into a boost::future or the reverse. (It's slightly less trivial if you want to use a mixture of futures and shared_futures, but it should still be manageable.)
Indeed a wrapper is trivial. The problem is where library A uses boost::future and library B uses std::future and your code has to work with both. In case you think that probably okay for open source libraries, imagine mixing up a precompiled binaries compiled against different MSVCRT.DLL where "std::future" isn't the same thing. A codebase I currently work with uses both types of future in the same codebase. We use std::async to work around it a lot unfortunately. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/