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: Wed, 24 Aug 2005 16:42:02 +0200
On 23.08.2005, at 17:50, Stephan Huber wrote:
Hi,
<snip>
Sorry, there was a misunderstanding: DSO2 does NOT inherits any
classes from DSO1, instead DSO2 calls a subclass (defined in DSO1) of
a class of DSO2. In this subclass inside DSO1 the dynamic_cast fails.
Here's some pseudo-code to explain my settings better:
DSO1 (my framework):
class Pickable {} // abstract class, defined only in the header-file.
class Visitor : public DSO2::Visitor {}
DSO2 (scengraph-framework):
scenegraph-stuff
DSO3 (my app):
class Cube : public DSO1::Pickable, public DSO2::Geode {}
main {
// create some cubes
// attach to scenegraph (DSO2)
// create visitor
// attach to scenegraph (DSO2)
//render-loop, which calls the visitor-subclass
}
So, inside DSO1::Visitor the dynamic_cast fails for DSO1::Pickable.
DSO1 is linked against DSO2, DSO3 is linked against DSO1 and DSO2,
So, what is wrong?
If you didn't get link errors as you compiled your framework, it looks
like, the compiler created RTTI info for Cube in this DSO, as expected.
When starting the app the dynamic link editor should now resolve the
vague linked RTTI objects (which has been written out along the
vtable), and recognise that there are two instances, one in App and one
in DSO 1 (your framework) - and only one should be selected as the
*active* object.
IMHO, the dynamic link editor should be able to resolve this! The two
(or better, all required) images are in memory, and it is only a
question of finding all references to a vague linked object and resolve
it to only one - of possible several - instance.
But it looks like, it didn't work.
My suspicion is, the RTTI info of DSO1::Pickable references an address
of the RTTI for Cube which is located in App. But in DSO1, there is
another RTTI for Cube, which will be referenced from dynamic_cast and
used for the comparison. And these two addresses are not equal.
Unfortunately, i found very little info about vague linked objects and
how the Mach-O dynamic link editor handles them. In fact, they are
mulitble defined symbols, and as such they *need to* be handled
differently than normal symbols, which - if they are defined multible,
will cause certain other trouble.
On the other hand, the RTTI will be treated like the vtable, and if the
vtable works and RTTI not, it looks very very odd.
Maybe this is a bug in the dynamic link editor or in dynamic_cast, but
i'm unsure.
Is the vtable working correctly?
(means polymorphic calls of member functions of class Cube from DSO1) ?
Is class Cube a template?
If the vtable works correctly, then i'm 99% sure it is a bug, elsewhere
in the tools (or it is just required - for Mach-O, that we have to link
to the app).
To workaround this issue, i would create another DSO which contains
class Cube. Then link the App and DSO1 against it.
Hope, then it will work.
Andreas
(I can see the subclasses of Cube inside the debugger, even inside the
failing function of DSO1)
Thanks again,
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
_______________________________________________
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