Re: [Threads-devel] Status

From: Anthony Williams (anthony_at_[hidden])
Date: 2008-03-11 17:14:56

Quoting Frank Mori Hess <frank.hess_at_[hidden]>:

> On Tuesday 11 March 2008 13:36 pm, Anthony Williams wrote:
>> No, it's not finished yet. Detlef posted a draft on the WG21 wiki, but
>> it's password protected. The paper is strongly based on N2276
>> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2276.html),
>
> Interesting.  The packaged_task part seems to have a lot of overlap with
> promise.  Wouldn't you get the same functionality from a boost::function<R
> ()> plus a promise as you get from packaged_task?  Maybe I'm just not fully
> grasping its purpose.

packaged_task can be implemented on top of a promise, but it is  
included because wrapping a function to get a future is expected to be  
a common operation. It can be used to build a thread pool, or just to  
get a return value from a thread.

> Also, have you considered supporting implicit conversions between future<U>
> and future<V> where there is an implict conversion between U and V?  My
> libpoet library does that, and it's helpful for passing futures between
> active object functors that return futures and accept them as arguments.

I haven't considered that. It seems awkward to me, as you could start  
with a future<U>, convert to future<V>, then to future<W>, then to  
future<X>, then to future<Y>. In each case there would be an implicit  
conversion, but you wouldn't normally be able to convert a U to a Y  
(too many UDCs). For this to work, therefore, you'd have to wrap the  
internal data with every conversion, otherwise some future<V>s could  
be converted to future<W>s, but not others. How did you handle this  
case?

> Are you planning to submit your future library to boost?  Is boost still used
> as a testing ground for standard proposals?  I suppose at this point, getting
> a futures proposal into C++0x might be the fastest way to get it into boost
> in any case.

Yes, I plan to submit it to boost. I was planning to add the  
future/promise/packaged_task part directly to boost.thread (someone  
already added a trac ticket for this functionality a while back), and  
then submit a full thread pool library for review, which can then be  
used as a basis for a fresh proposal for TR2.

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