[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: RTTI / dynamic casts in KDE?
From:       Lubos Lunak <l.lunak () sh ! cvut ! cz>
Date:       2002-01-28 22:51:32
[Download RAW message or body]

On Mon 28. January 2002 22:47, Manuel Arriaga wrote:
> Hi Waldo, David,
>
> Thank you both for your replies.
>
> On Monday 28 January 2002 20:43, David Faure wrote:
> > On Monday 28 January 2002 21:32, Waldo Bastian wrote:
> > > On Monday 28 January 2002 11:07 am, Manuel Arriaga wrote:
> > > > I would like to know why this option is always used. Is it a
> > > > g++/libg++ problem? Or KDE "policy"? :-)
> > >
> > > It's KDE policy. Qt/Embedded usually gets compiled without rtti. Since
> > > we
> >
> > want
> >
> > > to be able to use parts of KDE with Qt/Embedded as well, that means we
> > > can't use rtti in those parts. rtti is also not reliable in combination
> > > with dynamically loaded code. Therefor the use of rtti is discouraged.
> >
> > I think this is wrong. We use RTTI in KDE itself, there's no reason we
> > would prevent others from doing so too !
>
> I just noticed that, from all the matches I saw when running
>
> $ grep "-fno-rtti" kdelibs-2.2.2/*
>
> , the only match in the actual toplevel Makefile is
>
> USE_RTTI =
>
> I don't know what this means, but I suppose that if no rtti option is
> passed to GCC then RTTI will be used. (Just guessing :-) )
>
> But I would be interested in knowing more about what Waldo mentioned: that
> "rtti is not reliable in combination with dynamically loaded code". Does
> this mean that using RTTI inside a shared library isn't a good idea (as it
> seems to happen with kdelibs??)? Or that RTTI shouldn't be used in programs
> which link against shared libraries at runtime? Or both?

 You can start here: http://gcc.gnu.org/ml/gcc/2001-12/msg00169.html

 In short, what I remember:  RTTI is fine as long as you don't use 
dynamic_cast accross dlopen().  I.e. let's say you have class B inheriting 
from A, application appl and DSO dso.so containing foo() . Now appl dlopens() 
dso.so and calls foo() in it, which does new B and returns that to appl. 
using a A* pointer. Appl then uses dynamic_cast to find out if the A* pointer 
actually points to a B object, and the correct behaviour of course would be a 
successfull dynamic_cast, however with gcc3 it will fail.
 I'm not going to repeat the technical details, but the result so far is that 
gcc folks refused to do anything about that for various reasons, and 
suggested to use RTLD_GLOBAL for dlopen(), which would fix dynamic_cast. 
However, RTLD_GLOBAL has other problems, like name clashes, so KDE can't(?) 
use it. That's why for QObject inherited classes using qt_cast is prefered.
 For more details, see the URL above.

-- 
 Lubos Lunak
 llunak@suse.cz ; l.lunak@kde.org
 http://dforce.sh.cvut.cz/~seli
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]