From: Hess, Frank (frank.hess_at_[hidden])
Date: 2007-03-12 14:49:18
> -----Original Message-----
> From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]]
> On Behalf Of Peter Dimov
> To elaborate on Chris's point, the significance of keeping the
producer
> and
> the consumer interface separate is that it allows future<R> to be made
> convertible to future<R2> whenever R is convertible to R2 (or R2 is
void);
> this also allows extensions in the spirit of Frank Mori Hess's
operator[],
Are you getting me confused with someone else? I don't remember any
operator[]? One additional feature I am planning to add to libpoet is
the ability to set a promise with a future. In terms of Chris's promise
class, that would be something like a
promise::operator()(const Future<T> &)
This occurred to me while thinking about writing an active queue example
program, where the queue would accept and return future<T> elements.
Allowing a promise to be set with a future value would save having to
poll the futures in the active queue object until they are ready to be
used as values to fulfill promises.
Frank