DRAFT document on coding conventions in kde libraries

[David Faure]

On Monday 06 March 2006 12:48, Mirko Boehm wrote:
> On Monday 06 March 2006 09:40, Allan Sandfeld Jensen wrote:
> ...
> > It is unreliable across shared libaries. If you have a non-QObject based
> > heirachy you should implement your own type-system rather than rely on
> > dynamic_cast.
> Can you give a bit of information about 
> - on what platforms such problems arise
> - and what compiler versions are affected? 
> 
> I have heard (altough I was unable to reproduce the link) that such problems 
> have been solved with more recent GCCs. Which would be a criteria to what 
> versions we support. 

It only works if dlopening with RTLD_GLOBAL, which we don't do by default.
So every module is in its own 'typeinfo namespace', so to speak.
With RTLD_GLOBAL (KLibLoader::globalLibrary()) it would work, but the downside
is that if two modules define a class (or link to libraries which define a class) with 
the same name you get crashes. Like it used to happen between libfam's Client
and kwin's Client class before it got namespaced.

(ah where is Michael Matz these days? he was the expert on such matters :) )

> qobject_cast is fine for QObject derivates, but we will not get around with 
> not using dynamic_cast in any KDE library code. 

Using dynamic_cast for K* or Q* in kdelibs library code is fine since it's not across 
dlopened modules.

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).