----- Original Message ----- From: "Johan Torp" <johan.torp@gmail.com> To: <boost@lists.boost.org> Sent: Monday, May 12, 2008 12:14 PM Subject: Re: [boost] Re view Request: future library (N2561/Williams version)
I thought the most common use case for futures was the active object pattern. We should all try to agree what use cases/design patterns/higher level abstractions are most important and which we want to support. IMHO, this should be top priority for the "future ambition". Even though no higher level abstractions built on futures will make it to C++0x or boost anytime soon, it's important that the future interface needn't change to support them in the - future :)
I don't know if the most common use case is the active object pattern, I use it every time I call a functions whic could finish or not depending on its internals. Some times the function sould wait on some messages and then the best is to return a future. But the function can also finish on the same thread if it don't needs external interaction. The client could later on wait in the future (active) or attach a callback to be called when the future is ready (reaction). For example: { // ... future<T> f = call_somme_fct(); // ... // when the result is needed either wait by using it or if (!f) // attach some callback and change the intenal state else // continue // ... } I agree with you that the best test for the future interface is to show some good usages in the tutorial and examples of the library. The threadpool library could be one, but not the only one. Imagine now we had a function which returs a value and had an out parameter (maybe by reference) Result f(InOut& ref); Now we want to refactor this function (either because the new implementation will introduce an IO wait, or because the old blocking implementation could not be supported. Which should be the interface of the new function. The first thing could be to try with future<Result> f(InOut& ref); but nothing forbids the caller to use the ref parameter before the operation has completed and which could be invalid. If we want consistency what we would need is something like future<Result> f(future<InOut&>& ref); IMO this do not works in any proposal? Do we need future to works with in/out references? Yet another example future<Out&> f(); Note that future<Out&> and future<InOut&> should not mean the same. Do we need two future of reference classes? future<InOut&> will need a constructor future<InOut&>(InOut&), but the assocaited promise should copy the value when doint the set_value. Any thought? Has all this a sense or I'm completly lost? This example was there only to introdude other use cases, and in particular future of reference types or pointer types. If you have a better choice for the f function do not hesitate. Anthony, sorry for short cut (futures instead of unique_future or shared_future). In order to be coherent with the thread library (mutex/shared_mutex), should't unique_future be named future? Vicente