Updated version of futures library

Hi all,

I've updated my futures library to include wait_for_any() and
wait_for_all().

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=
    jss::wait_for_any(futures.begin(),futures.end());

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
http://www.justsoftwaresolutions.co.uk/files/futures_documentation.html
and the files and tests are available at
http://www.justsoftwaresolutions.co.uk/files/n2561_futures_revised_20080530.zip

Anthony
--
Anthony Williams            | Just Software Solutions Ltd
Custom Software Development | http://www.justsoftwaresolutions.co.uk
Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Am Freitag 30 Mai 2008 11:54:59 schrieb Anthony Williams:
> unique_future<int> f1;
> shared_future<std::string> f2;
> unique_future<double> f3;
> unsigned const ready_index=wait_for_any(future1,future2,future3);

should this have been:
{{{
unique_future<int> f1;
shared_future<std::string> f2;
unique_future<double> f3;
unsigned const ready_index=wait_for_any(f1, f2, f3);
}}}
??



-- Maik
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Maik Beckmann <beckmann.maik@...> writes:

> Am Freitag 30 Mai 2008 11:54:59 schrieb Anthony Williams:
>> unique_future<int> f1;
>> shared_future<std::string> f2;
>> unique_future<double> f3;
>> unsigned const ready_index=wait_for_any(future1,future2,future3);
>
> should this have been:
> {{{
> unique_future<int> f1;
> shared_future<std::string> f2;
> unique_future<double> f3;
> unsigned const ready_index=wait_for_any(f1, f2, f3);
> }}}
> ??

Yes. That's what I meant. Thanks.

Anthony
--
Anthony Williams            | Just Software Solutions Ltd
Custom Software Development | http://www.justsoftwaresolutions.co.uk
Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Johan Torp]

Anthony Williams-4 wrote:

The documentation is available at
http://www.justsoftwaresolutions.co.uk/files/futures_documentation.html

Try clicking on the links in the documentation. They all point to:
http://www.justsoftwaresolutions.co.uk/files/index.html#xxx
rather than:
http://www.justsoftwaresolutions.co.uk/files/futures_documentation.html#xxx

Johan

Johan Torp <johan.torp@...> writes:

> Anthony Williams-4 wrote:
>>
>> The documentation is available at
>> http://www.justsoftwaresolutions.co.uk/files/futures_documentation.html
>>
>
> Try clicking on the links in the documentation. They all point to:
> http://www.justsoftwaresolutions.co.uk/files/index.html#xxx
> rather than:
> http://www.justsoftwaresolutions.co.uk/files/futures_documentation.html#xxx

Oops. That'll teach me to just rename the file.

It should be fixed now.

Thanks.

Anthony
--
Anthony Williams            | Just Software Solutions Ltd
Custom Software Development | http://www.justsoftwaresolutions.co.uk
Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Vicente Botet Escriba]

----- Original Message -----
From: "Anthony Williams" <anthony.ajw@...>
To: <boost@...>
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
> wait_for_all().
>
> 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=
>    jss::wait_for_any(futures.begin(),futures.end());
>
> 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
> http://www.justsoftwaresolutions.co.uk/files/futures_documentation.html
> and the files and tests are available at
> http://www.justsoftwaresolutions.co.uk/files/n2561_futures_revised_20080530.zip
>

Hello,

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
this class.

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.


Best,

Vicente


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

"vicente.botet" <vicente.botet@...> writes:

> From: "Anthony Williams" <anthony.ajw@...>
>> I've updated my futures library to include wait_for_any() and
>> wait_for_all().

>> The documentation is available at
>> http://www.justsoftwaresolutions.co.uk/files/futures_documentation.html
>> and the files and tests are available at
>> http://www.justsoftwaresolutions.co.uk/files/n2561_futures_revised_20080530.zip
>>
>
> 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
> this class.
>
> Does it mean that the future interface from 20080515 do not allows to
> implement this function in an efficient way?

That is correct.

> 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?

I think that it can be implemented most efficiently with access to the
internals of the futures. However, it is possible to implement a
packaged_task on top of a promise.

> Should a separated packaged_task library be accepted in boost with an
> implementation using the internals of another library?

I think that packaged_task is an important class from the user
perspective, as it simplifies task launching, which is one of the
common use cases I expect from a futures library. I therefore think it
should be provided, whatever underlying implementation we use.

> 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?

That is the intention. The scheduler can decide which thread to run
the task on, and when, without having to know the details of the task
or how it connects to its futures. The set_wait_callback feature
allows the scheduler to know when a thread blocks on the future
associated with a task, and therefore to be able to reschedule the
task associated with that future if appropriate.

> 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.

If there is something that cannot be done without access to the
internals, then it might mean that there is an abstraction missing. My
intent is to provide a minimal set of features that allow higher level
abstractions to be built. This is why I keep evolving the interface,
e.g. to add wait_for_any.

> 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.

The friend declarations mean that these classes are closely related
and need to access each other's internals. This is safe because they
are provided together as a coherent whole.

I do not agree with the idea of having a public backdoor.

Anthony
--
Anthony Williams            | Just Software Solutions Ltd
Custom Software Development | http://www.justsoftwaresolutions.co.uk
Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Frank Mori Hess]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 30 May 2008 05:54 am, Anthony Williams wrote:
> Hi all,
>
> I've updated my futures library to include wait_for_any() and
> wait_for_all().
>

It seems like you might want to have timed_wait_for_any() and
timed_wait_for_all() too?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIQE7L5vihyNWuA4URAmyoAJ9QPTvt0hgv+v1dab0Rj9VzHyY/HACguSIb
l1VJChzSdrzT+/Jn3NNWw8g=
=sBbw
-----END PGP SIGNATURE-----
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Hartmut Kaiser]

> I've updated my futures library to include wait_for_any() and
> wait_for_all().
>
> 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=
>     jss::wait_for_any(futures.begin(),futures.end());
>
> 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
> http://www.justsoftwaresolutions.co.uk/files/futures_documentation.html
> and the files and tests are available at
> http://www.justsoftwaresolutions.co.uk/files/n2561_futures_revised_2008
> 0530.zip

This reminds me of a discussion we had some time ago, namely overloading
operator&&() for futures allowing to achieve the same thing: waiting for all
of the futures:

    future<int> f1;
    future<double> f2;
    future<fusion::vector<int, double> > f3 (f1 && f2);

    fusion::vector<int, double> result = f3.get();   // waits for f1 and f2

Similarly, overloading operator|| would allow to wait for the first future
to finish only:

    future<int> f1;
    future<double> f2;
    future<variant<int, double> > f3 (f1 || f2);

    variant<int, double> result = f3.get();   // waits for first, f1 or f2

Regards Hartmut



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

"Hartmut Kaiser" <hartmut.kaiser@...> writes:

>> I've updated my futures library to include wait_for_any() and
>> wait_for_all().
>>
>> 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=
>>     jss::wait_for_any(futures.begin(),futures.end());
>>
>> 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
>> http://www.justsoftwaresolutions.co.uk/files/futures_documentation.html
>> and the files and tests are available at
>> http://www.justsoftwaresolutions.co.uk/files/n2561_futures_revised_2008
>> 0530.zip
>
> This reminds me of a discussion we had some time ago, namely overloading
> operator&&() for futures allowing to achieve the same thing: waiting for all
> of the futures:

Yes. I was trying to stay away from the overloaded operators, but this
is certainly the same issue.

Anthony
--
Anthony Williams            | Just Software Solutions Ltd
Custom Software Development | http://www.justsoftwaresolutions.co.uk
Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Frank Mori Hess <frank.hess@...> writes:

> On Friday 30 May 2008 05:54 am, Anthony Williams wrote:
>> Hi all,
>>
>> I've updated my futures library to include wait_for_any() and
>> wait_for_all().
>>
>
> It seems like you might want to have timed_wait_for_any() and
> timed_wait_for_all() too?

Yes, that might be sensible.

Anthony
--
Anthony Williams            | Just Software Solutions Ltd
Custom Software Development | http://www.justsoftwaresolutions.co.uk
Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Hartmut Kaiser]

> > This reminds me of a discussion we had some time ago, namely
> overloading
> > operator&&() for futures allowing to achieve the same thing: waiting
> for all
> > of the futures:
>
> Yes. I was trying to stay away from the overloaded operators, but this
> is certainly the same issue.

Are you interested in something like this?
What's your reason for 'staying away' from the operators so far?

Regards Hartmut



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Johan Torp]

Hartmut Kaiser wrote:

> Yes. I was trying to stay away from the overloaded operators, but this
> is certainly the same issue.

Are you interested in something like this?
What's your reason for 'staying away' from the operators so far?

There has been some confusion as to what the operator semantics should be. Instead of returning the first ready future, one could return a future holding the value of lhs.get() && rhs.get() as soon as this is computable.

I.e.  future<bool> operator&&(future<bool>& lhs, future<bool>& rhs) would return a new future which is equal to true, iff lhs.get()==true and rhs.get()==true. If either one returned false it would be false and otherwise the composed future would not be ready yet.

I think this is more natural semantics, but most people seem to think otherwise. Because of this confusion, I think we should leave the operators be. I believe this is what Anthony is referring to.

Note that if we let the operators map against the templated types operators as soon as they are computable, we could implement arithmetic operators too:
future<double> a,b,c;
future<double> d = a*(b+c*a); // Will become ready when a, b and c is ready
This would allow "lifting" of aribitrary arithmetic expressions to futures.

Johan

[Vicente Botet Escriba]

----- Original Message -----
From: "Hartmut Kaiser" <hartmut.kaiser@...>
To: <boost@...>
Sent: Friday, May 30, 2008 9:10 PM
Subject: Re: [boost] Updated version of futures library

>> I've updated my futures library to include wait_for_any() and
>> wait_for_all().
>>
>> 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=
>>     jss::wait_for_any(futures.begin(),futures.end());
>>
>> 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
>> http://www.justsoftwaresolutions.co.uk/files/futures_documentation.html
>> and the files and tests are available at
>> http://www.justsoftwaresolutions.co.uk/files/n2561_futures_revised_2008
>> 0530.zip
>
> This reminds me of a discussion we had some time ago, namely overloading
> operator&&() for futures allowing to achieve the same thing: waiting for
> all
> of the futures:
>
>    future<int> f1;
>    future<double> f2;
>    future<fusion::vector<int, double> > f3 (f1 && f2);
>
>    fusion::vector<int, double> result = f3.get();   // waits for f1 and f2
>
> Similarly, overloading operator|| would allow to wait for the first future
> to finish only:
>
>    future<int> f1;
>    future<double> f2;
>    future<variant<int, double> > f3 (f1 || f2);
>
>    variant<int, double> result = f3.get();   // waits for first, f1 or f2
>

Hello,

I think that the problem with the operator is not its implementation, but
its definition. Your proposal seams natural for  && and for || when the
types are different. But when we have comon types things start to be more
complicated for operator ||. When all are differents we can know via the
type which future has finished the first. This information is lost
otherwise.

Which type will have (f1 || f2) if
future<string> f1;
future<string> f2;

If we don't mind which future has finished, future<string> should be good
(does variant<string, string> work in this case?).

If we mind a future<pair<unsigned, string> > . The first component give the
index, athe second the result.

The problem is that this do not scale to more that 2 futures. Which type
will have (f1 || f2|| f3) if
future<string> f1;
future<string> f2;
future<int> f3;

future<variant<string, int> > f3 (f1 || f2 || f3);
or
future<pair<unsigned, <variant<string, int> > > f3 (f1 || f2 || f3);

Vicente



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Hartmut Kaiser]

vicente.botet wrote:

> > This reminds me of a discussion we had some time ago, namely
> overloading
> > operator&&() for futures allowing to achieve the same thing: waiting
> for all of the futures:
> >
> >    future<int> f1;
> >    future<double> f2;
> >    future<fusion::vector<int, double> > f3 (f1 && f2);
> >
> >    fusion::vector<int, double> result = f3.get();   // waits for f1
> and f2
> >
> > Similarly, overloading operator|| would allow to wait for the first
> future to finish only:
> >
> >    future<int> f1;
> >    future<double> f2;
> >    future<variant<int, double> > f3 (f1 || f2);
> >
> >    variant<int, double> result = f3.get();   // waits for first, f1
> or f2
>
> I think that the problem with the operator is not its implementation,
> but
> its definition. Your proposal seams natural for  && and for || when the
> types are different. But when we have comon types things start to be
> more
> complicated for operator ||. When all are differents we can know via
> the type which future has finished the first. This information is lost
> otherwise.

Valid point. But this information can be retained easily by returning a pair
from the composed future (see below). The types in the list have to be
collapsed, for sure.

> Which type will have (f1 || f2) if
> future<string> f1;
> future<string> f2;
>
> If we don't mind which future has finished, future<string> should be
> good (does variant<string, string> work in this case?).

variant<string, string> will compile, but obviously doesn't make any sense.
If all future return types are identical the variant can be dropped
completely.

> If we mind a future<pair<unsigned, string> > . The first component give
> the index, and the second the result.
>
> The problem is that this do not scale to more that 2 futures. Which
> type will have (f1 || f2|| f3) if
> future<string> f1;
> future<string> f2;
> future<int> f3;
>
> future<variant<string, int> > f3 (f1 || f2 || f3);
> or future<pair<unsigned, <variant<string, int> > > f3 (f1 || f2 || f3);

I'ld suggest to use the latter one. The unsigned for the index of the
finished future and the variant holding all different possible return types
(or just the return type if all types are identical):

future<string> f1, f2;
future<int> f3;
future<pair<unsigned, variant<string, int> > > f4 (f1 || f2 || f3);
 
and

future<string> f1, f2, f3;
future<pair<unsigned, string> > f4 (f1 || f2 || f3);

which scales well for arbitrary numbers of parameters. Which shows another
advantage of this syntax: you don't have to provide N overloads for
wait_all/wait_any for N possible parameters, but only 2 or 3.

Regards Hartmut


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Hartmut Kaiser]

Johan Torp wrote:

> >> Yes. I was trying to stay away from the overloaded operators, but
> this is certainly the same issue.
> >
> > Are you interested in something like this?
> > What's your reason for 'staying away' from the operators so far?
>
> There has been some confusion as to what the operator semantics should
> be.
> Instead of returning the first ready future, one could return a future
> holding the value of lhs.get() && rhs.get() as soon as this is
> computable.
>
> I.e.  future<bool> operator&&(future<bool>& lhs, future<bool>& rhs)
> would
> return a new future which is equal to true, iff lhs.get()==true and
> rhs.get()==true. If either one returned false it would be false and
> otherwise the composed future would not be ready yet.

Doing it the way you're proposing implies shortcutting operator&&(), which
can't be implemented. OTOH, writing fusion::vector<bool, bool> doesn't imply
this and is no deviation from the generic case.

> I think this is more natural semantics, but most people seem to think
> otherwise. Because of this confusion, I think we should leave the
> operators
> be. I believe this is what Anthony is referring to.
>
> Note that if we let the operators map against the templated types
> operators
> as soon as they are computable, we could implement arithmetic operators
> too:
> future<double> a,b,c;
> future<double> d = a*(b+c*a); // Will become ready when a, b and c is
> ready
> This would allow "lifting" of aribitrary arithmetic expressions to
> futures.

This isn't possible in the generic case, because not all types provide the
corresponding operators. Additionally, this applies the operators to the
results and not the futures itself, where my proposal adds semantics for the
operators in terms of the futures and not their results.

Regards Hartmut





_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Frank Mori Hess-2]

On Saturday 31 May 2008 14:30, Hartmut Kaiser wrote:
> > I.e.  future<bool> operator&&(future<bool>& lhs, future<bool>& rhs)
> > would
> > return a new future which is equal to true, iff lhs.get()==true and
> > rhs.get()==true. If either one returned false it would be false and
> > otherwise the composed future would not be ready yet.
>
> Doing it the way you're proposing implies shortcutting operator&&(),
> which can't be implemented.

left-to right evaluation can't be short-circuited, but he's talking about
short circuiting in time, as either the lhs or rhs futures complete.

> > Note that if we let the operators map against the templated types
> > operators
> > as soon as they are computable, we could implement arithmetic
> > operators too:
> > future<double> a,b,c;
> > future<double> d = a*(b+c*a); // Will become ready when a, b and c is
> > ready
> > This would allow "lifting" of aribitrary arithmetic expressions to
> > futures.
>
> This isn't possible in the generic case, because not all types provide
> the corresponding operators.

So?  That just means something like

future<A> fa;
future<B> fb;
future<C> fc;
fc = fa + fb;

will compile if and only if

A a;
B b;
C c;
c = a + b;

compiles.  What's the problem with that?



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Hartmut Kaiser]

> On Saturday 31 May 2008 14:30, Hartmut Kaiser wrote:
> > > I.e.  future<bool> operator&&(future<bool>& lhs, future<bool>& rhs)
> > > would return a new future which is equal to true, iff
> > > lhs.get()==true and rhs.get()==true. If either one returned false
> it
> > > would be false and otherwise the composed future would not be ready
> > > yet.
> >
> > Doing it the way you're proposing implies shortcutting operator&&(),
> > which can't be implemented.
>
> left-to right evaluation can't be short-circuited, but he's talking

Right, that's exactly my point.

> about short circuiting in time, as either the lhs or rhs futures
> complete.

Didn't we talk about operator&&()? No 'either/or' here, only both futures.
Additionally, the same comments apply as outlined below.

> > > Note that if we let the operators map against the templated types
> > > operators as soon as they are computable, we could implement
> > > arithmetic operators too:
> > > future<double> a,b,c;
> > > future<double> d = a*(b+c*a); // Will become ready when a, b and c
> > > is ready This would allow "lifting" of aribitrary arithmetic
> > > expressions to futures.
> >
> > This isn't possible in the generic case, because not all types
> provide
> > the corresponding operators.
>
> So?  That just means something like
>
> future<A> fa;
> future<B> fb;
> future<C> fc;
> fc = fa + fb;
>
> will compile if and only if
>
> A a;
> B b;
> C c;
> c = a + b;
>
> compiles.  What's the problem with that?

No problem here.

My main point was that such operator overloads apply to the result types and
not the futures themselves, which adds unnecessary semantics and defeats
separation of concerns. And, BTW, this is very much like the default
conversion operator to the result type for the futures which - as most have
agreed - is a bad idea.

Regards Hartmut




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Frank Mori Hess-2]

On Saturday 31 May 2008 17:14, Hartmut Kaiser wrote:

> > On Saturday 31 May 2008 14:30, Hartmut Kaiser wrote:
> > > > I.e.  future<bool> operator&&(future<bool>& lhs, future<bool>&
> > > > rhs) would return a new future which is equal to true, iff
> > > > lhs.get()==true and rhs.get()==true. If either one returned false
> >
> > it
> >
> > > > would be false and otherwise the composed future would not be
> > > > ready yet.
> > >
> > > Doing it the way you're proposing implies shortcutting operator&&(),
> > > which can't be implemented.
> >
> > left-to right evaluation can't be short-circuited, but he's talking
>
> Right, that's exactly my point.
>
> > about short circuiting in time, as either the lhs or rhs futures
> > complete.
>
> Didn't we talk about operator&&()? No 'either/or' here, only both
> futures. Additionally, the same comments apply as outlined below.

I'm pretty sure he's not talking about your "wait_for_all" operator&&() at
all, he's talking about one with semantics closer to the "real" operator&&
defined by the language.

> My main point was that such operator overloads apply to the result types
> and not the futures themselves, which adds unnecessary semantics and
> defeats separation of concerns. And, BTW, this is very much like the
> default conversion operator to the result type for the futures which -
> as most have agreed - is a bad idea.

It only appears to defeat "separation of concerns" because you're not
separating your definition of the future logical operator overloads from
his.  They really are two different ideas and are not useful for the same
things.  Personally, I don't particularly want to see a future library
overload any logical operators at all, or at least have the overloads
sequestered in separate headers that aren't included by any of the other
future library headers.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Hartmut Kaiser]

Frank Mori Hess wrote:

> > > > > would be false and otherwise the composed future would not be
> > > > > ready yet.
> > > >
> > > > Doing it the way you're proposing implies shortcutting
> > > > operator&&(), which can't be implemented.
> > >
> > > left-to right evaluation can't be short-circuited, but he's talking
> >
> > Right, that's exactly my point.
> >
> > > about short circuiting in time, as either the lhs or rhs futures
> > > complete.
> >
> > Didn't we talk about operator&&()? No 'either/or' here, only both
> > futures. Additionally, the same comments apply as outlined below.
>
> I'm pretty sure he's not talking about your "wait_for_all" operator&&()
> at all, he's talking about one with semantics closer to the "real"
> operator&& defined by the language.

Sure, I understand. But the issue is that these are very similar to the
proposed math operators in the sense that they add semantics in terms of the
future results not the futures themselves.

> > My main point was that such operator overloads apply to the result
> > types and not the futures themselves, which adds unnecessary
> semantics
> > and defeats separation of concerns. And, BTW, this is very much like
> > the default conversion operator to the result type for the futures
> > which - as most have agreed - is a bad idea.
>
> It only appears to defeat "separation of concerns" because you're not
> separating your definition of the future logical operator overloads
> from his.  

This is just wrong and I don't think I gave you any reason to assert this.
Please refrain from imposing something I didn't say just for the sake of
making your point.

> They really are two different ideas and are not useful for
> the same things.  

I'm perfectly aware of this. And actually I expressed exactly the same by
pointing out the main difference between the two sets of operators: the
logical operators I proposed are for the futures themselves while the others
are related to the future results.

But you're diligently ignoring my point: overloading the operators for the
future results is conceptually equivalent to having a default conversion
operator to the result type for the future itself! And for that reason I
would not like to see something like that in the future library.

OTOH, IMHO, having the logical operators alone improves code readability,
simplifies the implementation (by avoiding multiple overloads for different
parameter counts), allows to build more complex logical execution
restrictions as (f1 || f2) && f3 (which is not possible using the proposed
wait_for_all and wait_for_any), and all that without having to sacrifice any
of the existing functionality.

> Personally, I don't particularly want to see a future
> library overload any logical operators at all, or at least have the
> overloads sequestered in separate headers that aren't included by any
> of the other future library headers.

That's a matter of taste, for sure. But would you mind telling us why you
don't want to have these? Your opinion sounds to be quite strong, so you
must have good reasons!

Regards Hartmut


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost