Another option that has been around for a number of years is:
http://doc.qt.io/qt-5/qtconcurrent-index.html
Futures for C++11 at Facebook
81–84 of 84 posts
Re: Futures for C++11 at Facebook
#82Earlier quoted context omitted.
If I compare the three alternatives: - Standard blocking code in OS threads. - Future-based code. - Coroutines with explicit annotation. The latter is probably only viable for very large organizations in terms of engineering cost. The other two are doable for smaller organizations.
Can you explain why? Futures seem to be much more intrusive than the other two.
They are intrusive in the sense that the code looks much different. On the other hand, I'd guess they are less error prone. Marking up syscalls would be a constant cognitive load, since you have to remember to do it each time (or else maintain an abstraction layer). But once you've decided to use futures, that's just how you do async.
Re: Futures for C++11 at Facebook
#83Can someone explain to me what does it add over http://www.boost.org/doc/libs/1_58_0/doc/html/thread/synchro... and pros/cons ? Thanks.
It is along the same lines as boost's futures implementation. We have a different mechanism for expressing thread management, born out of trial and error and Facebook engineer feedback. At the time we set out to write this boost futures were slow and buggy (1.53), and C++ standard monadic futures proposals were in very early stages (it now appears that there will be monadic futures in C++17). I do not know if boost f…
They seem to be more robust, but boost::future::then() has weird design that makes it all but useless for real-life use. They return the same kind of future that std::async() does, i.e. its destructor blocks until the future is ready. In other words, you can't write "fire and forget" code:
void run_and_report()
{
something_long_running()
.then([=]{ report_results() });
} // blocks here until the then() block executesRe: Futures for C++11 at Facebook
#84Earlier quoted context omitted.
E came out in 1997. From my perspective, Scala and C++11 are the backward ducks (unless you can point to something earlier using the Scala/C++11 nomenclature). I agree the Scala/C++11 way might make a little more sense intuitively, but it really doesn't help flipping the definitions around.
It's much older than that. See https://en.wikipedia.org/wiki/Futures_and_promises The distinction between futures and promises in the wikipedia article matches Scala's terminology exactly.
Yes, Wikipedia's terminology exactly matches that of Scala, but that's because Wikipedia references a Scala SIP ;)
It's always bothered me that Baker and Hewitt felt the need to coin the term "future" when they were clearly aware of "promise" and "eventual". Their main distinction seems to be that a future is a 3-tuple (process, cell, queue). One can argue that their future meets the "read-only view" definition because cell is only to be written to by the same tuple's process. But they never explicitly distinguish a future as "a read-only placeholder view of a variable," and E was the first publicly-available language to make that very distinction (please correct me if I'm wrong), only they happened to use "promise" in that regard.
In any case, I trust your judgement on the matter more than my own, just wish everyone had picked a nomenclature and stuck with it.