From: Florian Schintke (schintke_at_[hidden])
Date: 2005-08-17 04:14:18
> > You asked for comments, so here goes: I find the apparently
> > copious use of implicit conversions disturbing. Especially
> > disturbing is the fact that futures seem to have both
> > incoming and outgoing implicit conversions.
> In direct discussions with Thorsten I strongly objected against having an
> operator T(), he want's to see the commenst on this list anyway...
> Regards Hartmut
I am neither an C++ expert nor do I know the internal reasons why
inmplicit conversion may be awkward, but as Thorsten I like the
futures including the implicit conversion. In the following I try to
explain my reasons for this.
Futures can be used for asynchronous function calls, but futures could
(with another implementation) also be used for lazy evaluation.
>From the programmers point of view it is nice, if you can specify the
behaviour of your code by just changing the declaration of your
variables and do not have to change anything else.
// select one of the following declarations
// here the single call is visible (explanation see below)
int f = fac(15);
future<int> f = fac(15);
future<int,lazy> f = fac(15);
// ... do something else ...
// ... later use f (maybe at multiple locations in the code)
// without any syntactical change ...
cout << f << endl;
With this schema one could easily change the computational model from
synchronous, asynchronous (concurrently) and lazy. Missing the
implicit conversion one would have to change every use of f to f().
If f() is once evaluated (waited for the asynchronous call) f behaves
like a normal variable. The function is not evaluated again if f is
used again. Why should one have to write () at each usage of this
variable? This would be misleading and suggest that something is
called or evaluated every time (including side effects of fac()), wich
is not the case.
-- Florian Schintke <schintke_at_[hidden]>, http://www.zib.de/schintke/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk