From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2008-05-19 09:36:02
-----BEGIN PGP SIGNED MESSAGE-----
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 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
-----END PGP SIGNATURE-----
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk