Darryl Green said: >> -----Original Message----- >> From: William E. Kempf [mailto:[EMAIL PROTECTED]] >> >> Dave Abrahams said: >> > Hm? How is the result not a result in my case? >> >> I didn't say it wasn't a result, I said that it wasn't "only" a > result. >> In your case it's also the call. > > Regardless of whether it invokes the function the result must always be > associated with the function at some point. It would be nice if this > could be done at creation as per Dave's suggestion but providing > behaviour like the futures alexander refers to. That is, bind the > function, its parameters and the "async_result" into a single > aync_call/future object that is a function/executable object. It can be > passed to (executed by) a thread or a thread_pool (or whatever).
I'm not sure that binding the result and "the function" at creation time is that helpful. Actual results aren't that way. This allows you to reuse the result variable in multiple calls to different functions. But if people aren't comfortable with this binding scheme, I'm not opposed to changing it. Doing so *will* complicate things a bit, however, on the implementation side. So let me explore it some. >> It's not "thread-creation" in this case. You don't create threads > when >> you use a thread_pool. And there's other examples as well, such as > RPC >> mechanisms. And personally, I find passing such a "creation > parameter" to >> be turning the design inside out. > > But this doesn't (borrowing Dave's async_call syntax and Alexander's > semantics (which aren't really any different to yours): Dave's semantics certainly *were* different from mine (and the Futures link posted by Alexander). In fact, I see Alexander's post as strengthening my argument for semantics different from Dave's. Which leaves us with my semantics (mostly), but some room left to argue the syntax. > async_call<double> later1(foo, a, b, c); > async_call<double> later2(foo, d, e, f); > thread_pool pool; > pool.dispatch(later1); > pool.dispatch(later2); > d = later1.result() + later2.result(); You've not used Dave's semantics, but mine (with the variation of when you bind). >> More importantly, if you really don't like the syntax of my design, it > at >> least allows you to *trivially* implement your design. Sometimes > there's >> something to be said for being "lower level". > > Well as a user I'd be *trivially* implementing something to produce the > above. Do-able I think (after I have a bit of a look at the innards of > bind), but its hardly trivial. The only thing that's not trivial with your syntax changes above is dealing with the requisite reference semantics with out requiring dynamic memory allocation. But I think I can work around that. If people prefer the early/static binding, I can work on this design. I think it's a little less flexible, but won't argue that point if people prefer it. -- William E. Kempf [EMAIL PROTECTED] _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost