Review Request: future library (Gaskill version)

[braddock]

I wanted to formally request a review of my Futures library.
Latest Version: http://braddock.com/~braddock/future/

The library has matured greatly over the past year.  It has been heavily
used as a key component in a mid-sized commercial
application on both Linux and Windows.  Extensive unit tests and (just
now) documentation have been written - in fact there are more than twice
as many lines of test code and documentation than are in the library
proper.

The library incorporates many ideas from this list, from other prospective
submissions, other languages, and from academic papers.

The library does not currently use jamfiles or boostdoc (I tried I really
did).  It is a header-only library.  The documentation is currently
straight HTML, and should be very easy to translate to boostdoc if the
submission looks good.

NOTE - to avoid confusion, note that there is an older 2005 boost.future
candidate in the vault by Thorsten Schuett that is not related to mine
(although it was studied early on).

Thanks,
Braddock Gaskill
braddock@...

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

[Peter Dimov-5]

Braddock Gaskill:

>I wanted to formally request a review of my Futures library.
> Latest Version: http://braddock.com/~braddock/future/
>
> The library has matured greatly over the past year. ...

I no longer like future<>::cancel. :-) Have you considered the alternative
of automatically invoking the cancel handler when no futures remain? This
requires that a promise and a future be created at once:

    pair<promise,future> pc = create_channel();

or, if empty futures are allowed:

    future f; // empty/detached
    promise p(f); // attach p to f

This mirrors the future's ability to detect the lack of a promise object.

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

[Frank Mori Hess]

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

On Wednesday 09 April 2008 22:17 pm, Peter Dimov wrote:
> I no longer like future<>::cancel. :-) Have you considered the alternative
> of automatically invoking the cancel handler when no futures remain? This
> requires that a promise and a future be created at once:
>
>     pair<promise,future> pc = create_channel();

Would that really be necessary?  Presumably, you would only want it to call
the cancel handler when the future reference count makes the transition from
1 to 0, not potentially multiple times while the reference count sits at 0.

> or, if empty futures are allowed:
>
>     future f; // empty/detached
>     promise p(f); // attach p to f

- --
Frank
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFH/hfz5vihyNWuA4URAhHvAJ4vohVgFRV3DeMVEt2fJrYSmYOzOwCgtMv/
8tdNg8GH5nAnp/25GlewS9g=
=S9UK
-----END PGP SIGNATURE-----
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Anthony Williams-3]

Braddock Gaskill <braddock@...> writes:

> I wanted to formally request a review of my Futures library.
> Latest Version: http://braddock.com/~braddock/future/
>
> The library incorporates many ideas from this list, from other prospective
> submissions, other languages, and from academic papers.

Have you looked at N2561
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2561.html)? What do
you think? I should have an implementation ready soon, which I was intending
to submit to boost.

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]

Hello,

How do your library positions with respect to the standard proposals?
N2561 Anthony Williams: An Asynchronous Future Value
N2094 Howard Hinnant: Multithreading API for C++0X - A Layered Approach,

N2185 Peter Dimov: Proposed Text for Parallel Task Execution,

N2276 Anthony Williams: Thread Pools and Futures.

Good luck
_____________________
Vicente Juan Botet Escriba
----- Original Message -----
From: "Braddock Gaskill" <braddock@...>
To: <boost@...>
Sent: Thursday, April 10, 2008 3:39 AM
Subject: [boost] Review Request: future library (Gaskill version)

>I wanted to formally request a review of my Futures library.
> Latest Version: http://braddock.com/~braddock/future/
>
> The library has matured greatly over the past year.  It has been heavily
> used as a key component in a mid-sized commercial
> application on both Linux and Windows.  Extensive unit tests and (just
> now) documentation have been written - in fact there are more than twice
> as many lines of test code and documentation than are in the library
> proper.
>
> The library incorporates many ideas from this list, from other prospective
> submissions, other languages, and from academic papers.
>
> The library does not currently use jamfiles or boostdoc (I tried I really
> did).  It is a header-only library.  The documentation is currently
> straight HTML, and should be very easy to translate to boostdoc if the
> submission looks good.
>
> NOTE - to avoid confusion, note that there is an older 2005 boost.future
> candidate in the vault by Thorsten Schuett that is not related to mine
> (although it was studied early on).
>
> Thanks,
> Braddock Gaskill
> braddock@...
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>

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

[braddock]

On Thu, 10 Apr 2008 21:53:33 +0200, vicente.botet wrote:
> How do your library positions with respect to the standard proposals?
> N2561 Anthony Williams: An Asynchronous Future Value
> N2094 Howard Hinnant: Multithreading API for C++0X - A Layered Approach,
>
> N2185 Peter Dimov: Proposed Text for Parallel Task Execution,
>
> N2276 Anthony Williams: Thread Pools and Futures.

Hi Vincente,

The Dimov and Hinnant proposals were primary sources of inspiration of
this library when it was written last spring.  Much of the exception
transport code is from Peter's other N2096 proposal.

I will look at Anthony's newer standards proposals this weekend and give a
comparison.

        -braddock


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

[braddock]

On Thu, 10 Apr 2008 05:17:25 +0300, Peter Dimov wrote:
> I no longer like future<>::cancel. :-)

future<T>::cancel is an impurity - I completely agree and devoted an
aside to that in my documentation.  But many will find it useful.

Future variables really should have nothing to do with task management.
This is a major confusion which I've seen in prior future implementations
and standard proposals.  

Futures themselves should not be inherently tied to thread creation or
anything else...very limiting.  I provide a few hooks so that you can tie
futures to any scheduler, rpc scheme, or other asynchronous "backend".

> Have you considered the alternative
> of automatically invoking the cancel handler when no futures remain? This
> requires that a promise and a future be created at once:
>
>     pair<promise,future> pc = create_channel();

The thought crossed my mind, but there are too many places in real-world
usage (I've had a lot now) where I find I want to get a future from a
promise.  I think it might be awkward to store both, and defeats the
intention of automatic cancelation.

> or, if empty futures are allowed:

I allow empty futures.  I tried without, but it got too awkward at times.

>     future f; // empty/detached
>     promise p(f); // attach p to f

If I can create a new promise from a future, then I can no longer detect
a "broken promise" exception (when the last promise associated with a
future goes out of scope for whatever reason, possibly leaving a future
forever waiting).

Thanks,
Braddock Gaskill



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

[Peter Dimov-5]

Braddock Gaskill:

>>     pair<promise,future> pc = create_channel();
>
> The thought crossed my mind, but there are too many places in real-world
> usage (I've had a lot now) where I find I want to get a future from a
> promise.  I think it might be awkward to store both, and defeats the
> intention of automatic cancelation.

Can you please go into more detail?

It seems to me that if you need to create futures on demand, then the
non-automatic cancelation should not be used. If some future holder calls
cancel, later futures created by this promise will not work. I can't think
of a situation where this would be desirable.

Storing a future in addition to the promise does disable the implicit
cancelation - by design; presumably if you need the capability to create
more futures at some later point, you don't want the task canceled in the
meantime. And if you don't mind the task being canceled since you no longer
need to create futures, you just reset() your local future copy.

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

[Frank Mori Hess]

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

On Friday 11 April 2008 10:36 am, Peter Dimov wrote:

> It seems to me that if you need to create futures on demand, then the
> non-automatic cancelation should not be used. If some future holder calls
> cancel, later futures created by this promise will not work. I can't think
> of a situation where this would be desirable.
>
> Storing a future in addition to the promise does disable the implicit
> cancelation - by design; presumably if you need the capability to create
> more futures at some later point, you don't want the task canceled in the
> meantime. And if you don't mind the task being canceled since you no longer
> need to create futures, you just reset() your local future copy.

Would support for releasing a future's reference count be acceptable in this
scheme?  That is, something like

future<void> fire();
//...
{
        future<void> forget = fire();
        forget.release(); // promise is not cancelled when forget destructs
}

Releasing a future would make the associated promise uncancelable, would this
be a problem?

Tangentially, would the addition of a weak_future make future reference
counting more palatable?

- --
Frank
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFH/44n5vihyNWuA4URAlNeAKCTcBdPz6E1EHb8NvOdQ8tHfolVcACePJ/t
npAO6T8CpEfjrLdADCrenwc=
=UQK4
-----END PGP SIGNATURE-----
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Peter Dimov-5]

Frank Mori Hess:

> Would support for releasing a future's reference count be acceptable in
> this
> scheme?  That is, something like
>
> future<void> fire();
> //...
> {
> future<void> forget = fire();
> forget.release(); // promise is not cancelled when forget destructs
> }

Good point about fire and forget tasks. I'm not sure I have a satisfactory
answer yet. There is no way to distinguish a result-only task from a
perform-side-effects task automatically, so the user must have some way to
say which is which.

On the other hand, a newly created promise doesn't have a cancel handler by
default, so whoever installs the cancel handler (the executor) can easily
take an argument that disables said installation.

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

[Peter Dimov-5]

> http://braddock.com/~braddock/future/

I have some more questions related to the callback support.

1. If thread A is blocked waiting for a future and thread B puts a value
into the promise, is A unblocked right away, or do the callbacks complete
first? In other words, is A guaranteed to observe the side effects of the
callbacks?

2. What is the motivation for allowing more than one callback? This turns
the promise into a signal. Usually we want to keep components separate and
composable. Can't we just allow set_ready_handler and F*
get_ready_handler<F> (a-la function<>::target)? The client can then install
a signal.

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

[Vicente Botet Escriba]

Hello Peter,

this future library use your exception_ptr (providing a partial emulation of
N2179) and as I supose should be the case of any future implementation.

Do you plan to submit your implementation to Boost?

Best regards?
_____________________
Vicente Juan Botet Escriba


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

[Peter Dimov-5]

vicente.botet:
> Hello Peter,
>
> this future library use your exception_ptr (providing a partial emulation
> of
> N2179) and as I supose should be the case of any future implementation.
>
> Do you plan to submit your implementation to Boost?

My implementation is merely a proof of concept. I know Anthony Williams has
one (specific to MSVC) that is much more impressive (although I don't see it
in the SVN). I see that Emil Dotchevski also has something along these lines
in boost/exception/cloning.hpp. The future library also seems to contain an
enhanced implementation.

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

[braddock]

On Thu, 10 Apr 2008 21:53:33 +0200, vicente.botet wrote:
> How do your library positions with respect to the standard proposals?
> N2561 Anthony Williams: An Asynchronous Future Value

I've now taken a good look at the recent C++0X N2561 "An Asynchronous Future
Value" proposal.

Both my library and N2561 are heavily based on Peter Dimov's earlier API... I
dare say a few method name changes would make N2561 a proper subset of my
future and promise classes and future_wrapper helper.

I'm disregarding the future C++ move semantics, of course.  
We need a future<C++0x>::wait() for that... :)

unique_future<T> is an interesting concept.  Still wrapping my head around that.

My base classes offer two features which N2561 does not (and which I would
really hope to see in any C++0X standard).

--
1) First - future<T>::add_callback(f).  

add_callback is a hook called when the future is fulfilled.  End
users probably shouldn't have to touch it, but framework authors (who
write schedulers, asio, co-routines, etc) will DEFINITELY need it.  

add_callback() enables the following:

-Future Operators ((f1 && f2) || (f3 && f2) etc) - With add_callback, custom
future_operators can be written by users.

-Guarded Schedulers (See my library doc "Future Concept Tutorial" section at
http://braddock.com/~braddock/future) - Guards are a fundamental concept in the
academic future languages I've studied (see some of Ian Foster's papers on
Strand and PCN, for example).  I have found you can do some amazing things with
a guarded task scheduler (I've implemented one outside the future lib).

-Basic "future fulfillment" event notification (ie, just use add_callback as an
event handler).  Gives you essentially a signals/slot capability. Not a fan.

An alternative to add_callback() would be to provide just the operators
themselves - Guards can reasonably be derived from the combination ops.

Any of these mechanisms solve the busy wait in the N2561 motivating example.

--
2) Second - Lazy Futures.  

This is something I picked up from the Oz language future implementation, and
have found very useful.  A Lazy Future essentially flags itself when it is
"needed" - ie, when someone is blocked on a f.wait(), and f.get(), or has
explicitly called "f.set_is_needed()".  This allows, for example, a task to
only process _IF_ the result is actually needed.  

Again, see my library doc Tutorial where I show how to easily create a "Lazy
Job Queue".  Permits nice Memoization patterns as well.

Lazy Futures are also needed for "Lazy Future Streams".  A Stream is the
primary means of inter-task communication in future-related academic languages.
It permits producer/consumer patterns and one-to-many channels.  A Lazy stream
allows the producer task to produce new items only as fast as his fastest
consumer needs them (See Ian T. Foster's work again - or my
test_future.hpp unit test code).

Note I provide an easy-to-use future stream library with std iterator interface.

I also provide a future::cancel(), which has been discussed in the other
posts and which I'm not terribly attached to.

I really like seeing the N2561 C++ proposal uses a split
future/promise. Broken_promise exceptions have saved me many times in
real-world applications. And I like that you aren't using the implicit
type conversion (which has bitten me many times in real-world
applications! I only use my future::get() method now).

(I still provide implicit conversion, but would take it out very fast if others
are no longer attached to it).

Braddock Gaskill

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

[braddock]

On Sun, 13 Apr 2008 15:54:08 +0300, Peter Dimov wrote:
> I have some more questions related to the callback support.
>
> 1. If thread A is blocked waiting for a future and thread B puts a value
> into the promise, is A unblocked right away, or do the callbacks complete
> first? In other words, is A guaranteed to observe the side effects of the
> callbacks?

Hi Peter,
No, someone waiting on the future is not guaranteed to see callback
side-effects. All listeners are notified and the future_impl mutex
unlocked before the callbacks are called.

> 2. What is the motivation for allowing more than one callback? This turns
> the promise into a signal.

Hehe, I go back and forth on one or many callbacks every time I revisit the
design - last time being last week.

My justification is that add_callback() is really needed for authors of
other frameworks to hook into things (see prior post on guards and
operators).  My fear with only one callback is that, for example,
ASIO adds future support, uses add_the_callback internally, and later a
 user of ASIO uses add_the_callback for his own purposes and breaks
 ASIO.

I have considered making add_callback a friend function in a separate
future_ext.hpp header just to distance it from standard future<> usage.  It
is really only necessary to make the library extensible.

Braddock Gaskill

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

[braddock]

I have added a new API section to my future library documentation.
The new section documents the library class and method prototypes.

http://braddock.com/~braddock/future/index.html#api

        -braddock

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

[braddock]

On Fri, 11 Apr 2008 17:36:43 +0300, Peter Dimov wrote:
>>>     pair<promise,future> pc = create_channel();
>>
>> The thought crossed my mind, but there are too many places in real-world
>> usage (I've had a lot now) where I find I want to get a future from a
>> promise.  I think it might be awkward to store both, and defeats the
>> intention of automatic cancelation.
>
> Can you please go into more detail?

Frank nailed it with the fire-and-forget example, but I did go back and
grep through my application code to see where I was deriving futures from
promises.

1) I converted a promise to future when I needed status functions like
ready() from the future.  I've kept the promise interface pretty narrow.
So that usage could be changed if promise was made broader.

2) In my scheduler I had a "class task" object for each job which contained
a promise.  The user could also hold a handle to this task object and get a
copy of the corresponding future.  I suppose code like that could be
restructured if the extra constraint was justified.

  -braddock

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

[Vicente Botet Escriba]

Hello Gaskill,

From: "Braddock Gaskill" <braddock@...>
To: <boost@...>
Sent: Monday, April 14, 2008 12:55 AM
Subject: Re: [boost] Review Request: future library (Gaskill version)


<snip>

>> 2. What is the motivation for allowing more than one callback? This turns
>> the promise into a signal.
>
> Hehe, I go back and forth on one or many callbacks every time I revisit
> the
> design - last time being last week.
>
> My justification is that add_callback() is really needed for authors of
> other frameworks to hook into things (see prior post on guards and
> operators).  My fear with only one callback is that, for example,
> ASIO adds future support, uses add_the_callback internally, and later a
> user of ASIO uses add_the_callback for his own purposes and breaks
> ASIO.
>
> I have considered making add_callback a friend function in a separate
> future_ext.hpp header just to distance it from standard future<> usage.
> It
> is really only necessary to make the library extensible.

I use to put these kind of interfaces in a backdoor class which is a friend
class .
This pattern was already used by the thread class in order to separate the
safe interface(scoped_lock) and the unsafe one(lock/unlock), but was this
backdoor was on a detail namespace and not in the public interface). The new
thread library do not contains nymore this indirection.

The user of the library is not aware of this interface, but the author of
other library will use this backdoor class knowing that the door it opens is
a little bit more risky or unsafe and need a careful usage.

  template<typename R> class future
  {
     // ...
   private:
       friend template <typename R> class future_backdoor;
       callback_reference add_callback(const boost::function<void (void)>
&f);
       void remove_callback(callback_reference &ref);
    }

// future_backdoor.hpp

 // ...

  template<typename R> class future_backdoor {
    future<R>& fut_;
  public:
        future_backdoor(future<R>& fut): fut_(fut){}
        callback_reference add_callback(const boost::function<void (void)>
&f) {return fut_.add_callback(f)}
        void remove_callback(callback_reference &ref) {return
fut_.remove_callback(ref)}
  }

The aware user could use this as follows:

    future<T> fut;
    //...
    future_backdoor<T> bd_fut(fut);
    bd_fut.add_callback(f);

or directly

    future_backdoor<T>(fut).add_callback(f);

future_backdoor behaves like unsafe cast, a little bit as for example
const_cast.

What do you think?


_____________________
Vicente Juan Botet Escriba

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


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

[Vicente Botet Escriba]

----- Original Message -----
From: "Braddock Gaskill" <braddock@...>
To: <boost@...>
Sent: Monday, April 14, 2008 12:33 AM
Subject: Re: [boost] Review Request: future library (Gaskill version)

> On Thu, 10 Apr 2008 21:53:33 +0200, vicente.botet wrote:
>> How do your library positions with respect to the standard proposals?
>> N2561 Anthony Williams: An Asynchronous Future Value
>
> I've now taken a good look at the recent C++0X N2561 "An Asynchronous
> Future
> Value" proposal.
>
> Both my library and N2561 are heavily based on Peter Dimov's earlier
> API...  I
> dare say a few method name changes would make N2561 a proper subset of my
> future and promise classes and future_wrapper helper.

I thought that the future and promise separation was proposed by Christopher
Kohlhoff
http://www.nabble.com/-futures--composite-or-to9069443.html#a9473680 :)
I think that you should add the reference to his post.

> I'm disregarding the future C++ move semantics, of course.
> We need a future<C++0x>::wait() for that... :)
>
> unique_future<T> is an interesting concept.  Still wrapping my head around
> that.

Me too.

There is still the packaged_task class. What do you think about?

> My base classes offer two features which N2561 does not (and which I would
> really hope to see in any C++0X standard).
>
> --
> 1) First - future<T>::add_callback(f).
>
> add_callback is a hook called when the future is fulfilled.  End
> users probably shouldn't have to touch it, but framework authors (who
> write schedulers, asio, co-routines, etc) will DEFINITELY need it.
>
> add_callback() enables the following:
>
> -Future Operators ((f1 && f2) || (f3 && f2) etc) - With add_callback,
> custom
> future_operators can be written by users.

>From the new documentation these operators are already provided by your
library.
I don't like too much the overloading of the && and || operators when they
don't have logical semantics, but this is only a question of style and
taste. maybe & and | are less controversal. And find very strange the
function op()

> -Guarded Schedulers (See my library doc "Future Concept Tutorial" section
> at
> http://braddock.com/~braddock/future) - Guards are a fundamental concept
> in the
> academic future languages I've studied (see some of Ian Foster's papers on
> Strand and PCN, for example).  I have found you can do some amazing things
> with
> a guarded task scheduler (I've implemented one outside the future lib).

I like this usage of guards. Interesting. Could you add the reference in the
documentation?
I'll take a look.

> -Basic "future fulfillment" event notification (ie, just use add_callback
> as an
> event handler).  Gives you essentially a signals/slot capability. Not a
> fan.
>
> An alternative to add_callback() would be to provide just the operators
> themselves - Guards can reasonably be derived from the combination ops.
>
> Any of these mechanisms solve the busy wait in the N2561 motivating
> example.

I have not found the use of wait in the example ...

> --
> 2) Second - Lazy Futures.
>
> This is something I picked up from the Oz language future implementation,
> and
> have found very useful.
Could you add the referece.
A Lazy Future essentially flags itself when it is

> "needed" - ie, when someone is blocked on a f.wait(), and f.get(), or has
> explicitly called "f.set_is_needed()".  This allows, for example, a task
> to
> only process _IF_ the result is actually needed.
>
> Again, see my library doc Tutorial where I show how to easily create a
> "Lazy
> Job Queue".  Permits nice Memoization patterns as well.
>
> Lazy Futures are also needed for "Lazy Future Streams".  A Stream is the
> primary means of inter-task communication in future-related academic
> languages.
> It permits producer/consumer patterns and one-to-many channels.  A Lazy
> stream
> allows the producer task to produce new items only as fast as his fastest
> consumer needs them (See Ian T. Foster's work again - or my
> test_future.hpp unit test code).
>
> Note I provide an easy-to-use future stream library with std iterator
> interface.
>
> I also provide a future::cancel(), which has been discussed in the other
> posts and which I'm not terribly attached to.

IMO, the fact cancel can not really ensure the function is stopped makes
this operation not very safe. But maybe useful in some cases ...

> I really like seeing the N2561 C++ proposal uses a split
> future/promise. Broken_promise exceptions have saved me many times in
> real-world applications. And I like that you aren't using the implicit
> type conversion (which has bitten me many times in real-world
> applications! I only use my future::get() method now).
>
> (I still provide implicit conversion, but would take it out very fast if
> others
> are no longer attached to it).

I have just a question why there are three ways to get the value from a
future.
f, f() and f.get()?

I don't like too much the implicit conversion. N2561 has removed the
implicit conversion only from the unique_future but preserved it for
shared_future. Can some one explain why?

template <>
class unique_future<void>
{
public:
    // ...
    void move();  // <<<<<<<<<
    // ...
};
template <typename R>
class shared_future
{
public:
    // ...
    // retrieving the value
    operator R const & () const;  // <<<<<<<<<
    R const & get() const;
    // ...
};

If this implicit conversion is definitively removed, the operators || and &&
will not need any more the op function wich is quite odd.

Best
_____________________
Vicente Juan Botet Escriba


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

[Frank Mori Hess-2]

On Sunday 13 April 2008 22:06, vicente.botet wrote:
> > 1) First - future<T>::add_callback(f).
> >
> > add_callback is a hook called when the future is fulfilled.  End
> > users probably shouldn't have to touch it, but framework authors (who
> > write schedulers, asio, co-routines, etc) will DEFINITELY need it.

I agree with Braddock, although in libpoet I chose to make poet::future
depend on thread_safe_signals and so used signals/slots instead of rolling
yet another callback mechanism.  The schedulers in libpoet rely on the
signals coming from futures to know when one of the method requests in
their queue has become ready so they can wake up and process it.

> > add_callback() enables the following:
> >
> > -Future Operators ((f1 && f2) || (f3 && f2) etc) - With add_callback,
> > custom
> > future_operators can be written by users.
> >
> >From the new documentation these operators are already provided by your
>
> library.
> I don't like too much the overloading of the && and || operators when
> they don't have logical semantics, but this is only a question of style

I too dislike the operator|| and && overloading.  Hopefully, these
overloads are only enabled when the user deliberately includes a separate
header for them, making them optional.

--
Frank



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