David Abrahams wrote: > "Peter Dimov" <[EMAIL PROTECTED]> writes: > >> Using an undefined-yet Executor concept for the first argument. This >> is not much different from >> >> async_call<int> f( bind(g, 1, 2) ); >> // execute f using whatever Executor is appropriate >> int r = f.result(); >> >> except that the async_call doesn't need to know about Executors. > > ...and that you don't need a special syntax to get the result out that > isn't compatible with functional programming. If you want to pass a > function object off from the above, you need something like: > > bind(&async_call<int>::result, async_call<int>(bind(g, 1, 2)))
Hmm. Actually I'll need a similar three-liner: async_call<int> f( bind(g, 1, 2) ); // execute f using whatever Executor is appropriate // pass bind(&async_call<int>::result, &f) to whoever is interested Synchronous RPC calls notwithstanding, the point of the async_call is that the creation+execution (lines 1-2) are performed well in advance so that the background thread has time to run. It doesn't make sense to construct and execute an async_call if the very next thing is calling result(). So in a typical scenario there will be other code between lines 2 and 3. The bind() can be syntax-sugared, of course. :-) >>> int r = async_call<int>(create_thread(), bind(g, 1, 2)); >>> >>> int r = async(boost::thread(), g, 1, 2); > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> >>> int r = async_call<int>(rpc(some_machine), bind(g,1,2)); >>> >>> int r = async_call<int>(my_message_queue, bind(g,1,2)); >> >> All of these are possible with helper functions (and the <int> could >> be made optional.) > > Yup, note the line in the middle. The line in the middle won't work, actually, but that's another story. boost::thread() creates a "handle" to the current thread. ;-) Score another one for defining concepts before using them. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
