From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-05-30 09:02:56
----- Original Message -----
From: "Anthony Williams" <anthony.ajw_at_[hidden]>
Sent: Friday, May 30, 2008 11:54 AM
Subject: [boost] Updated version of futures library
> Hi all,
> I've updated my futures library to include wait_for_any() and
> The provided overloads allow either waiting on up to five futures
> known at compile time:
> unique_future<int> f1;
> shared_future<std::string> f2;
> unique_future<double> f3;
> unsigned const ready_index=wait_for_any(future1,future2,future3);
> or on a container of futures:
> std::vector<jss::shared_future<int> > futures;
> std::vector<jss::shared_future<int> >::iterator const future=
> In the first instance, they can be of distinct types, but in the
> latter, all the futures in the container must be of the same type.
> The documentation is available at
> and the files and tests are available at
in the implementation of wait_for_any you use the future_object_base which
is in the detail namespace and you have added an external_waiters member to
Does it mean that the future interface from 20080515 do not allows to
implement this function in an efficient way?
This was also the case of packaged_task which depends on
detail::future_object<T>. Does it mean that the future interface from
20080515 (extracting the packaged_task specifics) do not allows to implement
the packaged_task interface in an efficient way?
Should a separated packaged_task library be accepted in boost with an
implementation using the internals of another library?
Does the current packaged_task interface allows to implement a task
scheduler with features we have not determined yet, without modifying the
internals of packaged_task, and futures?
Does all this means that in order to implement higher level abstraction on
top of the future library we need to use the internals and/or change the
future library implementation?
IMO this is a symthom the future library interface is not enough open, and
than there are some internals abstractions that should be made public.
In addition you have added a lot of friends declarations, in particular
unique_future has 4 friend classes and shared_future has 3.
friend class shared_future<R>;
friend class promise<R>;
friend class packaged_task<R>;
friend class detail::future_waiter;
When we have such a number of friend classes this means that the non public
interface is a little bit public. In this case it will be better to identify
these interfaces and group them in a backdoor. This allows to separate the
interface used by applications and the one used by libraries.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk