Re: building gcc4... HELP!
Re: building gcc4... HELP!
- Subject: Re: building gcc4... HELP!
- From: David Leimbach <email@hidden>
- Date: Wed, 11 May 2005 07:51:24 -0700
On 5/10/05, Hugh Hoover <email@hidden> wrote:
>
> On May 10, 2005, at 17:03, David Leimbach wrote:
>
> > On 5/9/05, Hugh Hoover <email@hidden> wrote:
> >
> >> Hi - I found a bug in the libc++v3 library with dynamic_cast and,
> >> rather than just wait for Apple to fix it, I'm trying to build my own
> >> so I can fix it myself as a work-around.
> >>
> >>
> > What's the bug?
>
> If you have a template class that uses a base class with virtual
> functions AND you have ANOTHER template that accepts the base class
> and does a dynamic_cast to the template class AND you're using dylibs
> or frameworks or.. (any separately linked form that might generate a
> local copy of the template), then the dynamic_cast will fail in any
> module other than the one that actually creates the object.
> This is because a new instance of the type_info is created for each
> module that has it's own instantiation of the template, and the
> dynamic_cast code (apparently) does not perform a normalized (non-
> instance-specific) comparison between the source and destination types.
>
So
class A
{
virtual void foo ();
};
template <typename T>
class B : public A
{
};
template <typename T>
void blah (A * obj)
{
B<T> * bobj = std::dynamic_cast <B<T> * >(obj);
if (!bobj)
{
//fails even if B<T>'s instance is loaded...
}
}
The explicit instantiations of B<T> are implemented as "dylibs" or
some other dynamically loadable module of sorts.
I'm not sure this is a real bug. Do you at least declare the explicit
instantiation to exist in a common header file?
class B <char>;
class B <int>;
Then you might be able to get away with using the dynamic loading
tools to provide the implementation for the runtime linker from a
.dylib. The compiler needs to know of the type before doing anything
with:
B<char> * bobj = new B<char>();
blah <char> (bobj);
could work.
My example may be way off. :).
Templates are a compile time construct of the C++ language. There's
no easy way I know around this. The compilation unit pretty much has
to have the definition for any of the instantiations you might use
[due to the lack of "export" keyword support in gcc, but even then...
you still need to access the source]
> Was that as clear as mud? :) see my message in xcode-
> email@hidden on may 9 with the subject "bug?: templates,
> dynamic_cast and frameworks". It's slightly more clear. I also have
> a very short example that shows the problem in about 100 lines of code.
>
> I think now that I can work around the issue by only having a single
> instantiation of any template (-no-implicit-templates), but that's
> likely to be painful in the extreme. I'd rather have a proper
> dynamic_cast that doesn't depend on specific instances of type_info.
>
>
Yeah, it's a complex situation you've got there :).
Dave
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden