Posted 20 December 2013 - 03:19 PM
The concept itself is at least quite useful. There are plenty of cases where you need to wait for a particular series of tasks to finish, even if those tasks are batched to a large job system. They're very similar to any message system, albeit they only fire "once" and remember whether they've already fired or not.
Modern games also do a lot of request/response things to remote servers for DLC, friends list and status update, micro-transactions, etc. which is a great use of futures (or even async/await if it ever becomes widely available).
Remember, not every piece of code in a game is in some inner loop running thousands of times per frame.
The specific implementation of std::future may leave something to be desired. I don't know that there is much collective wisdom in the games industry to make a call on it one way or the other. A future can conceptually be tasked out to a thread pool; I don't know enough about the specific implementations of any to know if they are using a thread pool or not, however. You can write your own without much difficulty if you need to, however, and you could even replace std::future at a later date easily enough if you start writing code relying on it then later determine it has issues in its implementation.