2012/2/15 Patrick Ohly <[email protected]>: > On Wed, 2012-02-15 at 12:39 +0100, Krzesimir Nowak wrote: >> 2012/2/14 Patrick Ohly <[email protected]>: >> > 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 {}; > > That should work. It's a pity that the "void" type is treated > differently than other types. > > Anyway, I also went ahead and implemented the brute-force approach of > duplicating different operators this morning. See > for-master/dbus-blocking. We can replace that with a more elegant > implementation later.
If you are curious then my implementation is in my branch [1] (the ada8263c3f20a772928889503b92c272535d8ea8 commit). It should be API compatible with your for-master/dbus-blocking code. [1] https://meego.gitorious.org/~krnowak/meego-middleware/krnowaks-syncevolution/commits/cssr1 > -- > 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
