On Tue, 2012-02-14 at 16:02 +0100, Patrick Ohly wrote: > On Mon, 2012-02-13 at 14:50 +0100, Chris Kühl wrote: > > - Krzesimir implemented the missing functionality in the gio-gdbus > > wrapper and added code to do blocking calls with minimal extra code > > required in consuming classes. > > In addition to adding a block() method which executes the call, wouldn't > it be nicer to also overload the call operator such that if there is no > Callback_t parameter, all results are returned directly (special case > for a single return value) or as tuple (general case)? > > The block() call would be more efficient for large return values (avoids > one copying), but for small ones the ease of use certainly would be > worth it. > > I've experimented a bit with it and think it can be done.
... but there are complications. When the call operator is called with a boost::function as callback, the C++ compiler picks the operator implementation which has that type as last parameter, as intended (more specific alternatives are preferred). But when the result of boost::bind() is passed to the operator, the compiler ends up treating it like an arbitrary template class and tries to serialize it in the blocking call version of the call operator. To solve this, one would have to add more variants of the call operator - not nice. I'd prefer to change the C++ binding's API and offer a blocking call operator and an asynchronous start() call which is equivalent to the current call operator. Seems cleaner to me. > Is there still a need for the block() variant if there was a "normal" > blocking call operator()? I looked again at the concurrent-sync-sessions-r1 branch and found that the direct calling of the block() methods was already removed again in favor of some generic callback mechanism which stores the return values in some bound variables. I still think that a "normal" method call is much more intuitive. If I don't hear otherwise, then I'll rewrite the top of the branch to use the approach outlined above. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
