2012/2/14 Patrick Ohly <[email protected]>:
> On Tue, 2012-02-14 at 17:53 +0100, Krzesimir Nowak wrote:
>> 2012/2/14 Patrick Ohly <[email protected]>:
>> > 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 :-(
>
Got different idea about this yesterday at home - maybe we could just
use traits class for DBusClientCall. Traits struct would describe
callback type and return type. For void it would some empty struct
like struct VoidReturn {};
I am now experimenting with it, so I'll see how it works.
> 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.
>
>
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
