Re: frameworks, dynamic_cast and gcc 4.0
Re: frameworks, dynamic_cast and gcc 4.0
- Subject: Re: frameworks, dynamic_cast and gcc 4.0
- From: Andreas Grosam <email@hidden>
- Date: Tue, 23 Aug 2005 15:43:36 +0200
On 22.08.2005, at 17:56, Steve Baxter wrote:
Hi Stephan,
I ran into a problem like this as well. The problem seems to be a
difference in implementation between dynamic_cast in GCC 4.0 and in
most other compilers (or at least CodeWarrior and VC++).
It seems that GCC 4.0 treats classes linked in different shared units
as different, even if they have the same name. There is some good
information here:
http://gcc.gnu.org/faq.html#dso
Yeah, but it is also explained that RTTI symbols *have* to be resolved
propperly at load time. That means, if you perform a dynamic_cast in
DSO S1 you need to link against the DSO S2, where the class (and all
the type info) is defined and you also need to make the RTTI symbols
accessible in DSO S2.
Then, only one instance of RTTI is *active*.
You will see this problem if the same source file is linked or
included in more than one DSO (dynamic shared object).
Shouldn't i then get link errors (duplicate symbols)??
So then, you are doing something wrong. As mentioned, you need to link
against the DSO where the class is defined, instead of including the
source module into the calling DSO.
More irritatingly, you can run into this problem with fully-inline
classes - if the class header is included in more than one DSO, it
will end up with two type_info copies, one in each DSO (this can
happen very commonly with template code).
These constructs are indeed more complicated, especially dealing with
templates. However, if not otherwise stated explicitly in bold face,
you can rely on the tools! ;-)
The problem here is, that you don't get linker errors, when you just
not link against the DSO where the class template has been
instantiated. But you need to.
These constructs are said to have "vague linkage":
http://developer.apple.com/documentation/DeveloperTools/gcc-4.0.0/gcc/
Vague-Linkage.html
The reason for the problem seems to be that the GCC writers changed
GCC so that type_info was checked for equality by comparing addresses
rather than really comparing for equality. Two type_infos with
different addresses are always considered to be different even if they
are in fact identical. This was done for performance reasons - a
pointer comparison is (obviously) faster than a string compare.
That is true. And this works only under the assumption that the symbols
(or better objects) have been resolved propperly. Then, there is only
one *active* object, and this is the correct one.
I suspect this works OK within a single DSO - the linker discards
duplicate copies of the type_info constructs so you end up with only
one.
Yes, because the symbols will be resolved at link time, and only one
will be made the *active* object.
When you use shared libs, resolving occurs at load time, but the effect
is the same: one and only one object will be made the active one.
In case of RTTI, you also need to ensure that the selected active
object is the correct one, means, firstly you need to link against the
DSO where it is defined, and you also need to export the symbols. Then,
and only then, the dynamic linker can resolve the correct symbol at
load time.
I am not sure what you are supposed to do in multi-DSO applications
where the same template or inline class might be used in several DSOs
- I would want then to be treated as identical, but the GCC runtime
would not do this. This is probably going to be a show-stopper for us
- this works fine in VC++ and CodeWarrior though
Again, ensure you link against the DSO where the class is defined - and
do *not* include source modules in more than one DSO which are used in
your application.
Unless you only use dynamic_cast to check the type, but also call
member functions of this object, you need to link against this DSO
anyway!
Regards
Andreas
.
Does anyone know if there is a compiler switch or something to turn
type_info comparisons by equality rather than by address back on?
Cheers,
Steve.
On 22 Aug 2005, at 13:42, Stephan Huber wrote:
Hi all,
I switched with my code to XCode 2.1 and gcc 4.0. Now most of my
dynamic_casts are failing (they worked fine before XCode 2.1). And I
don't know why, my knowledge of the inners of the compiler etc is
limited.
To be precise: the dynamic_casts are working in the scope of the
application, but If I call a method/function inside my custom
framework which does a dynamic_cast, this dynamic_cast fails
To be more specific:
I declare a class inside my framework
class Foo : public osg::Object {...}
I create some objects inside the application and attach them to other
objects (they have a property osg::Object (which is declared in
another framework)) After a while I need to process the objects
inside my custom framework and there the dynamic_cast to Foo fails.
I found the following message in the archives
<http://lists.apple.com/archives/Xcode-users/2005/May/msg00315.html>
which describes my problem in a more complicated way, doing some
searches in the archives reveils some posts about similar problems,
the solution was to *export* the class-definition, but I can't find
any information how to do this, but maybe I'm dumb ;)
P.S. My code worked very well and reliable under gc 3.x and Panther...
Any help is greatly appreciated,
thanks in advance,
Stephan
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
This email sent to email@hidden
Stephen Baxter
Software Development Manager
Improvision
email@hidden
+44-2476-692229
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden