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>:
> 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.