• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: How is this not a complier error? (dynamic casting problem)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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
  • Follow-Ups:
    • Re: How is this not a complier error? (dynamic casting problem)
      • From: Andreas Grosam <email@hidden>
References: 
 >How is this not a complier error? (dynamic casting problem) (From: Zachary Pincus <email@hidden>)
 >Re: How is this not a complier error? (dynamic casting problem) (From: Andreas Grosam <email@hidden>)

  • Prev by Date: Re: multi-character character constant and CFString
  • Next by Date: Selecting alternative compiler via rules tab - compiler not listed
  • Previous by thread: Re: How is this not a complier error? (dynamic casting problem)
  • Next by thread: Re: How is this not a complier error? (dynamic casting problem)
  • Index(es):
    • Date
    • Thread