Help a mate: an extremely strange bug on GCC/ld ?

Olivier Goffart ogoffart at
Sat Dec 6 15:50:31 GMT 2008

Le samedi 6 décembre 2008, koos vriezen a écrit :
> 2008/12/6 Olivier Goffart <ogoffart at>:
> > Reimplementing an existing virtual method is fine if you can accept that
> > it is not called if the program reimplementing the class is not
> > re-compiled (i.e, if the feaure added in that implementation is
> > optional.)
> Huh, isn't that true for every source code that isn't compiled, ie.
> please explain.
> Koos

For this explanation, i assume you know what a virtual table is 

Let's suppose you have the class DolphinListView, which inherit from 
KCategorizedView which itself inherit from QListView

In KDE 4.1, KCategorizedView doesn't reimplement the virtual function 
rowsAboutToBeRemoved.  So DolphinListView's virtual table points to 

Now, in KDE 4.2,  KCategorizedView::rowsAboutToBeRemoved is reimplemented,  
but if dolphin is not compiled, DolphinListView's virtual table doesn't 
change and still points to QListView::rowsAboutToBeRemoved

That means that KCategorizedView::rowsAboutToBeRemoved will not be called for 
any call to this function.
That's ok if the code in the new KCategorizedView::rowsAboutToBeRemoved is 
just a bugfix or a new feature optional feature.  But this is not ok if some 
other code in other function of KCategorizedView relies on the fact that 
KCategorizedView::rowsAboutToBeRemoved should have been called.

I hope this answer the question.

(Note that I was wrong regarding the slot thing, since 
KCategorizedView::qt_metacall will lookup in the virtual table wrong 
information as well.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <>

More information about the kde-core-devel mailing list