This should be a regression of GCC and a new bug in 4.2 and later version. Someone said GCC 4.1.2 was ok. Please see below link: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37093 To be simpler, you can see comment#2, which shows a simple case to produce this bug. This bug leaves unfixed for more than a year. I'm afraid that we may make a decision to use other workarounds for we don't know how long it could be fixed. Cheers, Yongsheng -----Original Message----- From: syncevolution-bounces(a)syncevolution.org [mailto:syncevolution-bounces@syncevolution.org] On Behalf Of Patrick Ohly Sent: Saturday, September 19, 2009 10:22 PM To: SyncEvolution Subject: [SyncEvolution] gdbus-cxx and methods in base classes Hello! Yongsheng found a problem in the C++ D-Bus binding, triggered by this code: void Session::activate() { static GDBusMethodTable methods[] = { ... makeMethodEntry<ReadOperations, bool, ReadOperations::Config_t &, typeof(&ReadOperations::getConfig), &ReadOperations::getConfig> ("GetConfig"), ReadOperations is a private base class of Session, which was meant to inherit the implementation without writing any glue code. The problem is that the "void *data" pointer is a "Session *" for all interface methods, but the methodFunction template for getConfig casts from void * to ReadOperations, which is incorrect. I have been unhappy with the need to repeat method parameter types as template parameters of makeMethodEntry. It would be much more natural to write: makeMethodEntry(this, &ReadOperations::getConfig> "GetConfig") A traits class which hinges on the type of the second parameter then could provide the result of the call. The "this" pointer is passed so that its type is known and the cast can be generated correctly. I gave this a try and think it should work - except that g++ 4.3 and 4.4 crash when the type case is enabled in methodFunction2. Without that line, the code compiles. Darn. If anyone has an idea how to make this work with existing compilers, feel free to help me out. Yongsheng, in the meantime please work around the problem by writing some glue code (Session::getConfig, Session::getReports, ...). I don't want to make the makeMethodEntry<> calls any more complex while there still is a chance to make them simpler. -- 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.

I see. Here I mean using a *smart* and *elegant* method to solve this issue. Not write glue code. :-) what are "base pointer" and 'per-callback data'? How to find the method? Could you please explain it in more detail? Cheers, Yongsheng -----Original Message----- From: Ohly, Patrick Sent: Monday, September 21, 2009 3:27 PM To: Zhu, Yongsheng Cc: SyncEvolution Subject: RE: [SyncEvolution] gdbus-cxx and methods in base classes On Mon, 2009-09-21 at 03:33 +0100, Zhu, Yongsheng wrote: Yeah, that's the one. Please work around it by adding glue code for the affected methods to Session. I'll think a bit about how this can be solved more elegantly without triggering the compiler bug. Extending the gdbus core so that it calls the C callbacks with two parameters (base pointer + per-callback data) might work, then we can use the per-callback pointer to find the method that we need to call instead of using a template parameter. It would also allow us to bind arbitrary functions, not just class members. -- 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.

On Thu, 2009-10-08 at 17:33 +0100, Patrick Ohly wrote: Okay, done. See the updated "gdbus-cxx" branch. Yongsheng, can you review this so? It's ready to replace the current code in the "dbus-api" branch. I didn't get the "const methods" case to work. The last commit contains an example (hello_const) which is commented out at the moment, because enabling it demonstrates that registering such a const method fails. C++ experts to the rescue... On the other hand, this is not an essential feature as long as one controls the implementation of the methods. An extra "const" keyword can always be removed, even though it is not nice. -- 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.

On Wed, 2009-10-14 at 04:29 +0100, Zhu, Yongsheng wrote: The base class is only inaccessible in DBusObjectHelper. The class registering the method in the base class has access to it. So this example fails, as you said: class Test2 { public: void test2() {} }; class DBusTest : public Test, private Test2 { DBusTest(DBusConnection *conn) : .... { m_object.add(this, &Test2::test2, "Private"); .... But this code here works: m_object.add(static_cast<Test2 *>(this), &Test2::test2, "Private"); -- 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.