bug?: templates, dynamic_cast and frameworks
bug?: templates, dynamic_cast and frameworks
- Subject: bug?: templates, dynamic_cast and frameworks
- From: Hugh Hoover <email@hidden>
- Date: Mon, 9 May 2005 12:35:19 -0700
I'll spare you all the litany of woe and gnashing of teeth :)
I think I've found a problem with the gcc4/libstdcxx dynamic_cast
implementation.
I'd like to find out if anyone else has seen this and if they know of
a work-around. I'll be writing up a bug-report later today as I
finish analyzing this and create a test sample.
I have templates that uses an abstract class for a root class with
(some) implementation in a framework, like:
class Foo {
public:
virtual ~Foo(){}
virtual void doFoo() = 0;
protected:
Foo() {}
};
template <class T> class Bar : public Foo
{
...
public:
virtual void doFoo() { ... implementation ...}
};
template <class T> struct BarDo
{
void fooBlah(Foo*foo)
{
Bar<T> * bart = dynamic_cast<Bar<T>*>(foo);
...
}
};
It's more complicated than that, but that's the essential detail (i
think :).
In the framework, I create an instance of, say, Bar<int>* and return
it. In the mainline code, I later fetch that, but only know it as a
Foo*.
I then attempt a call to BarDo<int>::fooBlah(foo) - passing in what I
KNOW is a Bar<int> (I've verified addresses and contents of the
object - including vtable pointers, etc.)
The dynamic_cast FAILS! I always get NULL back.
I have tracked the problem down a bit, and in __dyamic_cast, from
libstdc++v3, I find that the type_info that's passed in to the
dynamic_cast is not the same one as is visible in the framework (ok -
I expect that, really and it SHOULD be ok).
I added some additional code in both the framework where the item is
created and in the main routine like:
const std::type_info& dtype(typeid(Bar<int>));
const char * tname = dtype.name();
In the framework, the reference to dtype is to one address, while in
the mainline, the reference is to a different address. I think
THAT's ok, but they should compare equal but apparently don't. The
NAME that's returned in both cases IS the same.
I haven't finished tracking down the code, but I think there's an
early-out attempt in do_dyncast code that's comparing pointers rather
than a normalized test, which is what I think the problem is.
Note that first, if everything's all in the same linked-module,
there's no problem because there's only one instance of the type_info.
Also, this all worked FINE under gcc3.3 and 3.1, so this is likely a
new optimization added in gcc4 (although I haven't found the
appropriate code diff yet).
I have NOT yet attempted to rebuild under 3.3 to see how that reacts,
but I also don't know if the gcc3.3 libstdc++ on 10.4 is identical to
the one under 10.3.8 and earlier.
Anybody have any insight on this?
Thanks,
Hugh Hoover
Enumclaw Software
_______________________________________________
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