-----BEGIN PGP SIGNED MESSAGE----- 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 boost::protect()? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFINupX5vihyNWuA4URAt0/AJ9WDjsz8KpTZx3P5xcCpqck3xLapwCdHPrf YbCeNge/oz3Nbz51kAD40tM= =S3P6 -----END PGP SIGNATURE-----