Boost logo

Boost :

From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2008-05-23 12:01:26

Hash: SHA1

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
Version: GnuPG v1.4.6 (GNU/Linux)


Boost list run by bdawes at, gregod at, cpdaniel at, john at