Adding new 'virtual' methods to KCalendarSystem

John Layt johnlayt at
Sat Jan 2 23:17:53 GMT 2010


In KCalendarSystem most methods are virtual to allow each calendar 
implementation to override with their particular calculations as required.  I 
need to add more virtual methods to support new features like Era-based 

The problem is there are no extra slots reserved in the virtual table, and the 
base class is not based on QObject so I can't use the slot trick described on 

I was wondering if instead I could add the virtual methods to the d-pointer 
instead and have each child class override that as required?

I was thinking it would look something like this:

// Base class

class CalBase
    virtual int calcFoo( int y, int m, int d );  // already exists
    int calcBar( int y, int m, int d );  // new 'virtual' method
    setBaseDpointer( CalBasePrivate * );  // new method
    CalBasePrivate * const d;  // already exists

    // No longer create base d-pointer here

int CalBase::calcBar( int y, int m, int d )
    return d->calcBar();

// Implementation of CalBasePrivate add new virtual method

class CalBasePrivate
    virtual int calcBar();  // new virtual method

int CalBasePrivate::calcBar( int y, int m, int d )
    return y + m + d;

// Implementation of CalX, no changes in header

CalX::CalX() : CalBase()
    setBaseDpointer( new CalXBasePrivate() ); // new

// Implementation of CalXBasePrivate, extends CalBasePrivate

class CalXBasePrivate :: CalBasePrivate
    virtual int calcBar();  // new virtual method

int CalXBasePrivate::calcBar( int y, int m, int d )
    return y * m - d;

Would this work?  Are there any problems with doing this besides performance?  
I'm assuming adding more virtual methods to the d-pointer would not break BIC?  
Would it be a bad idea to make the derived classes friends of the base to 
directly access the d-pointer, which might be needed anyway?

An alternative is to just do all the new implementations in the base class and 
have an if-else-if tree based on calendarType(), but that isn't very OO.

Or is there another better way?



More information about the kde-core-devel mailing list