Re: [boost] [futures] Future Containers?

From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2008-05-19 22:22:30

On Mon, May 19, 2008 at 9:36 PM, Frank Mori Hess <frank.hess_at_[hidden]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Sunday 18 May 2008 22:40 pm, Dean Michael Berris wrote:
>> Right now, having futures non-default constructable makes it hard(er)
>> to put them in standard containers.
>
> I believe futures should be default constructible.  The William's future
> already have an "empty" state, which can be reached by moving a future.  I
> made poet::future default constructible so they could be used in containers,
> and made default constructed futures throw an exception if someone attempts
> to wait on them.
>

This sounds like a good idea, waiting on a future that doesn't have an
associated promise should throw.

>> This now begs the question: Will there be, or should there be, special
>> classes of future containers that would specially be defined to work
>> with futures? For example, in associative containers we should be able
>> to access the elements using the index operator without having to
>> explicitly call 'wait()', or perhaps have special future container
>> iterators that allow for waiting on a future when dereferencing
>> "pointed to elements".
>
> Would this add anything besides automatically waiting for futures to become
> ready when they are accessed?  Automatic waiting is the reason some people
> don't like implicit conversion of futures to values (I actually don't like it
> so much myself any more).  They want points in the program where a future
> might block to be as explicit as possible.
>

For the special container types I've been pondering, aside from
automatically waiting on contained futures there's the possibility of
making standard algorithms more specialized for these container types
(or via tag dispatch).

Perhaps having a special std::transform() implementation (the five
argument version) that does a 'wait on any' future in the container
and in a non-deterministic order apply a function on the contained
future value that becomes available, and the result mapped to the
appropriate location in the resulting container.

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.