Re: [SyncEvolution] C++ D-Bus bindings + blocking calls

On Tue, 2012-02-14 at 17:53 +0100, Krzesimir Nowak wrote: > 2012/2/14 Patrick Ohly <patrick.ohly(a)intel.com&gt;: > > Here's a partial implementation. Not all combinations of number of > > parameters and return values are currently spelled out. Is there a > > better approach and would it be worthwhile? > > Well, specifiying 44 methods sounds like overkill to me. I do have > some idea, but I don't know if it will work. > > > Add another template parameter to DBusClientCall: > > template <class T, class R> > class DBusClientCall > { > public: >     typedef T Callback_t; >     typedef R Return_t; > ... > }; > > Add pure virtual method in DBusClientCall: > virtual Return_t demarshal(DBusMessagePtr &msg, DBusConnectionPtr &conn) = 0; > > Then example of blocking operator(): > > > Return_t operator () () > { >   // usual body - message creation, preparation, adding parameters... >   return sendAndReturn(msg); > } > > where sendAndReturn would be: > > Return_t sendAndReturn(GDBusMessagePtr &msg) > { >   // do synchronous call and throw an exception on error. >   GDBusMessagePtr reply(...); > >   return demarshal(reply, m_conn); > } We could use an empty tuple to handle a void return type. Same for a single return value. But the result wouldn't be very natural: the empty tuple could be ignored by the caller, but the single-value very much should be the return value, not some tuple containing it. > This is an idea, so I have no idea if it will work. :) Especially when > Return_t is void. Exactly :-(

So the question remains, is this useful enough to justify the effort (whether it is some cut-and-paste or further investigations around achieving this more elegantly)? -- 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.