An odd behavior of dynamic_cast
Hi all,
This is my first post. :-)
Recently, I found an odd behavior about dynamic_cast
across shared libraries.
This is my box:
linux kernel-2.4.21
gcc-3.4.3
(Check out my test_case.tar.bz2 for complete source
codes.)
I defined these classes and functions in libbase.so:
struct Base; // <- polymorphic
struct Tag; // <- non-polymorphic
struct VirtualTag; // <- polymorphic
Tag* getTag(Base* base)
{
return dynamic_cast(base);
}
VirtualTag* getVirtualTag(Base*)
{
return dynamic_cast(base);
}
I also defined these derived classes in libderived.so:
struct Derived0 : Base, Tag;
struct Derived1 : Base, VirtualTag;
Then I tested getTag() and getVirtualTag() in two ways:
test0: linked to libderived.so (and libbase.so) at
build time.
test1: dynamically loads libbase.so and libderived.so
by using dlopen() at runtime.
These two test cases basically does the same thing:
1. create Derived(0|1) instance.
2. do dynamic_cast by using get[Virtual]Tag()
function.
In test0, both getTag() and getVirtual() are ok (returns
non-NULL value).
But in test1, getTag() returns NULL while getVirtualTag()
returns non-NULL.
I expected that I got the same results in both cases...
In test1, typeid(Tag) is not unique.
Could anyone tell which behavior is right or bug?
Thanks.
--
STOP HIV/AIDS.
Yahoo! JAPAN Redribbon Campaign 2005
http://pr.mail.yahoo.co.jp/redribbon/
test_cast.tar.bz2
Description: test_cast.tar.bz2
An odd behavior of dynamic_cast
Hi all,
This is my first post. :-)
# I could not find a mailing list dedicated to c++ at
gcc.gnu.org.
# So I post this mailing list.
Recently, I found an odd behavior about dynamic_cast
across shared libraries.
This is my box:
linux kernel-2.4.21
gcc-3.4.3
(Check out my test_case.tar.bz2 for complete source
codes.)
I defined these classes and functions in libbase.so:
struct Base; // <- polymorphic
struct Tag; // <- non-polymorphic
struct VirtualTag; // <- polymorphic
Tag* getTag(Base* base)
{
return dynamic_cast(base);
}
VirtualTag* getVirtualTag(Base*)
{
return dynamic_cast(base);
}
I also defined these derived classes in
libderived.so:
struct Derived0 : Base, Tag;
struct Derived1 : Base, VirtualTag;
Then I tested getTag() and getVirtualTag()
in two ways:
test0: linked to libderived.so (and libbase.so)
at build time.
test1: dynamically loads libbase.so and
libderived.so
by using dlopen() at runtime.
These two test cases basically does the same thing:
1. create Derived(0|1) instance.
2. do dynamic_cast by using get[Virtual]Tag()
function.
In test0, both getTag() and getVirtual() are ok
(returns non-NULL value).
But in test1, getTag() returns NULL
while getVirtualTag() returns non-NULL.
I expected that I got the same results
in both cases...
In test1, typeid(Tag) is not unique.
Could anyone tell which behavior is right or bug?
Thanks.
--
STOP HIV/AIDS.
Yahoo! JAPAN Redribbon Campaign 2005
http://pr.mail.yahoo.co.jp/redribbon/
test_cast.tar.bz2
Description: test_cast.tar.bz2
re: An odd behavior of dynamic_cast
Hi Dan, > I think the right place for this question might have > been gcc-help (http://gcc.gnu.org/ml/gcc-help/). Thanks to Ben, I've already posted the same question to gcc-help. > > [ Why doesn't dynamic_cast work when I dlopen a > shared library? ] I've checked out http://gcc.gnu.org/faq.html#dso. But in fact, I'm writing python extention module, so I can't call dlopen() with RTLD_GLOBAL flag. My actual question is: - Why dynamic_cast across shared libraries works for VirtualTag in test1? (though I use dlopen() in test1.) - Is it correct to use this workaround (i.e. making a class polymorphic) when I can't use RTLD_GLOBAL flag? Thanks. --- Dan Kegel <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > [ Why doesn't dynamic_cast work when I dlopen a > shared library? ] > > I think the right place for this question might have > been > gcc-help (http://gcc.gnu.org/ml/gcc-help/). > Nevertheless, I think > http://gcc.gnu.org/faq.html#dso > should answer your question. > - Dan > > -- > Wine for Windows ISVs: http://kegel.com/wine/isv -- STOP HIV/AIDS. Yahoo! JAPAN Redribbon Campaign 2005 http://pr.mail.yahoo.co.jp/redribbon/
