From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2008-05-23 12:01:26
-----BEGIN PGP SIGNED MESSAGE-----
On Friday 23 May 2008 10:50 am, Johan Torp wrote:
> Frank Mori Hess wrote:
> > How about an additional future_select overload which accepts two
> > boost::shared_container_iterators as arguments, and returns a
> > future<shared_container_iterator>? The returned iterator would point at
> > the
> > future which is ready or has an exception. Then the caller could use the
> > returned iterator to erase the element from the container before calling
> > future_select again. The shared_container_iterator would insure the
> > input container of futures doesn't die before the return future becomes
> > ready.
> That would restrict users to put their futures in a container created as a
> shared_ptr, right?
Yes, but the shared_container_iterator isn't really necessary, I could make
future_select return a future<Iterator> for any type of iterator input. I
was just trying to make it safer. Unfortunately, even using
shared_container_iterator still wouldn't prevent the user from modifying the
container so as to invalidate the returned future iterator anyways. Maybe
I'll just suggest using shared_container_iterator in the docs.
> Yes, I'm thinking of a passive function which doesn't have an internal
> thread associated with it. One that is evaluated lazily as soon as someone
> is interested in it.
> I think this could be very useful, do you?
I don't know, it might be. I've never tried to program something using a lot
of nested lazy evaluation. Could you use boost::bind to achieve the same
effect? Doesn't it do something like this by default if you do a recursive
bind of a function to a parameter, and don't wrap the function in
-----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