site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=FPiFPzti79YsXsAcBKdqaskRXPjjj5kvSHM3+S0LedbgnkHMrvuSrND1p1RhBVzUoOJ9iNb5S7ClFw52LGNlTz6eqKF0MCUC92wPuwM6kdW4ESO0L+sVilGZuGcCTxWtrAw7TYzLZNuo0WMjeaSPR6s2N6pjZAs87wQtLxu+qVc= On 5/10/05, Hugh Hoover <hugh-dated-1116215619.acde2d@hooverzone.com> wrote:
On May 10, 2005, at 17:03, David Leimbach wrote:
On 5/9/05, Hugh Hoover <hugh@hooverzone.com> 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- users@lists.apple.com 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 (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com