From: "Wolfgang Bangerth" <[EMAIL PROTECTED]> > > > double d; > > > thread<double> t = spawn(foo)(a,b,c); > > > // do something else > > > d = thread.return_value(); > > > > A solution like this has been proposed before, but I don't like it. This > > creates multiple thread types, instead of a single thread type. I think > > this will only make the interface less convenient, and will make the > > implementation much more complex. For instance, you now must have a > > seperate thread_self type that duplicates all of thread<> except for the > > data type specific features. These differing types will have to compare > > to each other, however. > > Make the common part a base class. That's how the proposal I sent you does > it :-) > > > > async_result<double> res; > > thread t(bind(res.call(), a, b, c)); > > // do something else > > d = res.value(); // Explicitly waits for the thread to return a value? > > This does the same, indeed. Starting a thread this way is just a little > more complex (and -- in my view -- less obvious to read) than writing > thread t = spawn(foo)(a,b,c); > > But that's just personal opinion, and I'm arguably biased :-)
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() You could also consider the merits of providing an implicit conversion from async_result<T> to T. This approach doesn't get the asynchronous call wound up with the meaning of the "thread" concept. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
