I love the concept of futures and look forward to the completion of this library. However, do have one critisism. On 8/16/05, Thorsten Schuett <schuett@zib.de> wrote:
//double_[] creates a simple_future<double>
Forgive me if am missing the obvious, but is there a reason as to why you have double_ and int_, etc. with overloaded operator[] to create a simple_future as opposed to simply having a "make_future" function which automatically detects which instantiation of simple_future should be made based off of the return type of the function pointer/function object being passed. In other words, why have double_[ &double_func ]; int_[ &int_func ]; when you can simply have make_future( &double_func ); // detects the double return type and returns a simple_future< double > make_future( &int_func ); // detects the int return type and returns a simple_future< int > Having a make_future function gets rid of the need to explicitly state the return type of the function in the future's creation. Even still, if you actually want to be explicit, then why would you make the double_ and int_ types when the desired functionality already exists by just specifying the template arguments of simple_future? double_[ &double_func ] seems to offer no benefit over simple_future< double >( &double_func ), other than possibly less code to type. It seems to me like completely uneccessary code, especially since you have similar types for int and I'd imagine other built-ins. I don't really see an added benefit of these objects concerning the manner in which you are currently using them. -Matt Calabrese