Dave Abrahams said: >> Hmm... that would be >> an interesting alternative implementation. I'm not sure it's as >> "obvious" as the syntax I suggested > > Sorry, IMO there's nothing "obvious" about your syntax. It looks > cumbersome and low-level to me. Let me suggest some other syntaxes for > async_result, though: > > async_call<double> later(foo, a, b, c) > > or, if you don't want to duplicate the multi-arg treatment of bind(), > just: > > async_call<double> later(bind(foo, a, b, c)); > ... > ... > double d = later(); // call it to get the result out.
The two things that come to mind for me with this suggestion are: 1) You've explicitly tied the result into the call. I chose the other design because the result is just that, only a result. An asynchronous call can be bound to this result more than once. 2) You're still hiding the thread creation. This is a mistake to me for two reasons. First, it's not as obvious that a thread is being created here (though the new names help a lot). Second, and this is more important, you've bound this concept to boost::thread explicitly. With the fully seperated concerns of my proposal, async_result can be used with other asynchronous call mechanisms, such as the coming boost::thread_pool. asyc_result<double> res1, res2; thread_pool pool; pool.dispatch(bind(res1.call(foo), a, b, c)); pool.dispatch(bind(res2.call(foo), d, e, f)); d = res1.value() + res2.value(); > I like the first one better, but could understand why you'd want to go > with the second one. This is easily implemented on top of the existing > Boost.Threads interface. Probably any of my suggestions is. Yes, all of the suggestions which don't directly modify boost::thread are easily implemented on top of the existing interface. >> as evidenced by the questions I've raised here, > > Can't argue with user confusion I guess ;-) > >> but worth considering. Not sure I care for "spawn(foo)(a, b, c)" >> though. I personally still prefer explicit usage of Boost.Bind or some >> other binding/lambda library. But if you want to "hide" the binding, >> why not just "spawn(foo, a, b, c)"? > > Mostly agree; it's just that interfaces like that tend to obscure which > is the function and which is the argument list. OK. That's never bothered me, though, and is not the syntax used by boost::bind, so I find it less appealing. >> > This approach doesn't get the asynchronous call wound up with the >> meaning of the "thread" concept. >> >> If I fully understand it, yes it does, but too a lesser extent. What >> I mean by this is that the async_result hides the created thread >> (though you do get access to it through the res.thread() syntax). > > That's what we mean by the terms "high-level" and "encapsulation" ;-) Yes, but encapsulation shouldn't hide the implementation to the point that users aren't aware of what the operations actually are. ;) But I'll admit that some of my own initial confusion on this particular case probably stem from having my brain focused on implementation details. >> I found this >> surprising enough to require careful thought about the FULL example >> you posted to understand this. > > Like I said, I can't argue with user confusion. Does the name > "async_call" help? Certainly... but leads to the problems I addresed above. There's likely a design that will satisfy all concerns, however, that's not been given yet. -- William E. Kempf [EMAIL PROTECTED] _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost