> 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.
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-boun...@syncevolution.org 
[mailto:syncevolution-boun...@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.

_______________________________________________
SyncEvolution mailing list
SyncEvolution@syncevolution.org
http://lists.syncevolution.org/listinfo/syncevolution

Reply via email to