> > > async_result<double> later = spawn(foo)(a, b, c);
> >
> > Mustn't use the name spawn() here. It implies a thread/process/what ever
> > has been spawned at this point, which is not the case. Or has it (he says
> > later, having read on)?
>
> It has.
It must, because a/b/c might be temporaries. You must have started the new
thread and copied the arguments to the new thread before you can return
from the spawn call, since otherwise the temporaries might have been
destroyed in the meantime.
> Sorry, IMO there's nothing "obvious" about your syntax. It looks cumbersome
> and low-level to me.
Right. That's exactly my criticism. Calling a function on a new thread
should be just as simple as calling it sequentially. And
spawn(foo)(a,b,c);
i.e. not using the return value, should just create a detached thread.
> I'm sure I'm never biased <wink>, and I tend to like your syntax better.
> However, I recognize what Bill is concerned about. Let me suggest a
> compromise:
>
> async_result<double> later = spawn(foo)(a, b, c);
> ...
> thread& t = later.thread();
> // do whatever with t
> ...
> double now = later.join(); // or later.get()
The way I went is to derive async_result from thread, so you get the
.thread() function for free as a derived-to-base conversion. Actually,
async_result<>=thread<> and thread=thread_base in what I have, but that's
just naming.
> You could also consider the merits of providing an implicit conversion
> from async_result<T> to T.
Possible, but I'd say too confusing.
Cheers
W.
-------------------------------------------------------------------------
Wolfgang Bangerth email: [EMAIL PROTECTED]
www: http://www.ticam.utexas.edu/~bangerth/
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
