Tasks in the form of promises and futures have in C++11 an ambivalent reputation. On the one hand, they are much easier to use than threads or condition variables; conversely, they have a significant deficiency. They can not be composed. C++20 will overcome this deficiency.<\/p>\n
<\/p>\n
Before I write about extended futures, let me say a few words about the advantages of tasks over threads.<\/p>\n
The key advantage of tasks over threads is that the programmer has only to think about what has to be done and not how – such as for threads – it has to be done. The programmer gives the system some job to perform, and the system ensures that the job will be executed by the C++ runtime as smartly as possible. That can mean the job will be executed in the same process, or a separate thread will be started. That can mean that another thread steals the job because it is idle. Under the hood, a thread pool accepts the job and distributes it intelligently. If that is not an abstraction?<\/p>\n
I have written a few posts about tasks in the form of std::async<\/span>, std::packaged_task<\/span>, std::promise<\/span>, and std::future<\/span>. The details are here tasks<\/a>: But now the future of tasks.<\/p>\n The name extended futures is quite easy to explain. Firstly, the interface of std::future<\/span> was extended; secondly, there are new functions for creating compensable special futures. I will start with my first point. <\/p>\n<\/p>\n std::future<\/span> has three new methods.<\/a><\/p>\n An overview of the three new methods.<\/p>\n At first, to something quite sophisticated. The state of the future can be valid or ready.<\/p>\n Therefore (valid == true<\/span>) is a requirement for (ready == true<\/span>).<\/p>\n Whom such as I perceive promise and future as the endpoints of a data channel; I will present my mental picture of validity and readiness. You can see a picture in my post Tasks<\/a>.<\/p>\n The future is valid if there is a data channel to a promise. The future is ready if the promise has already put value into the data channel.<\/p>\n Now, to the method then<\/span>.<\/p>\n then<\/span> empowers you to attach a future to another future. Here it often happens that a future will be packed into another future. To unwrap the outer future is the job of the unwrapping constructor<\/span>.<\/em><\/p>\n Before I show the first code snippet, I have to say a few words about proposal n3721<\/a>. Most of this post is from the proposal to “Improvements for std::future<T> and Related APIs”. That also holds for my examples. Strangely, they often did not use the final get <\/span>call to get the result from the res <\/span>future. Therefore, I added to the examples the res.get<\/span> call and saved the result in a variable myResult. <\/span>Additionally, I fixed a few typos.Extended futures<\/h2>\n
std::future<\/h3>\n
\n
valid versus ready<\/h4>\n
\n
Continuations with then<\/h4>\n
<\/span><\/em><\/p>\n