Re: How is this not a complier error? (dynamic casting problem)
Re: How is this not a complier error? (dynamic casting problem)
- Subject: Re: How is this not a complier error? (dynamic casting problem)
- From: Zachary Pincus <email@hidden>
- Date: Tue, 26 Jul 2005 09:55:30 -0700
Andreas, Thanks for your help!
I've got some more details about my dynamic-downcast problem.
First, the problem disappears when I switch to gcc3.3 with gcc_select.
Second, you are right to wonder if the problem has to do with DSO
boundaries. My attempts to make complete test cases (as you suggest
below) did not re-create the bug. In fact, I *only* see the error if
the Image object was passed across a DSO boundary. If I make a new
one in situ, no error.
Now, I'm fairly sure that the RTTI information is being exported. I
don't think I've any of the "symbols hidden by default" flags on.
Moreover, the RTTI information seems to exist for the Image object
that can't be properly downcast, since I can call typeid and get the
correct name for the pointed-to object. Is there a better run-time
check to make sure that the RTTI information was properly exported?
Also, how do I force this information to be exported -- just
declare a class "extern"? In case there is some hidden interaction
causing symbols not to be exported by default, I'd like to see if
forcing them to be exported works.
Now, I'm combing through the exact GCC flags that the project is
actually compiled with, but I see nothing suspicious. Also, the fact
that changing to gcc3.3 without changing any other settings makes
things work all of a sudden worries me -- do gcc3.3 and gcc4.0 differ
in how they handle exported symbols?
Thanks,
Zach Pincus
Program in Biomedical Informatics and Department of Biochemistry
Stanford University School of Medicine
On Jul 26, 2005, at 4:28 AM, Andreas Grosam wrote:
On 26.07.2005, at 03:45, Zachary Pincus wrote:
Hello,
I'm running into a problem in my C++ code (which uses RTTI and
dynamic_cast) which I can only account to be a g++ compiler error.
snip
the result of the downcast looks strange.
Can you test whether a dynamic downcast is successful using these
classes:
template <int K>
class base
{
public:
enum { value = K };
virtual ~base() {}
};
template <typename T, int K>
struct derived : base<K>
{
derived(const T& v = T()) : x(v) {}
T x;
};
On XCode 1.5 (gcc-3.3) and XCode 2.1 (gcc-4.0.0), the dynamic_cast
works as expected.
Adding a namespace, does not break it, too.
So, one oddity I notice is that the run-time type of the
dereferenced pointers is NOT const, even though it should be.
It seems, the mangled names do not contain a qualifier for non
pointer types, that is:
typeid(const T).name() is_equal typeid(T).name()
typeid(volatile T).name() is_equal typeid(T).name()
where T is a non-pointer type.
This condition evaluates to true also:
( typeid(T) == typeid(const T) )
IMO, this treatment is questionable.
That does not mean, that the compiler is unable to distinguish this
types, though.
But I see no reason that imageBaseP, which points to an itk::Image
object, couldn't be down-cast to the same! Any thoughts?
IMO, the downcast should work.
The base class needs to be a polymorphic class of course, the
compiler would complain otherwise.
The types need to be complete, that means, include everything
necessary to instantiate a complete object. But i guess, the
compiler would also complain, otherwise.
Are the objects instantiated in the same library (DSO)? Is the call
to operator dynamic_cast in the same DSO?
If "No", you need to ensure that RTTI information is exported
accross DSOs - means your types (template classes) shall be exported.
hm, no more thoughts.
Andreas
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40onlinehome.de
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