cross-module RTTI issues
Hello, I'm not sure if this is even the right place to post this question, but I'm having some trouble with inheritance across shared library boundaries. I've read the CrossExtensionModuleDependencies Wiki node, and I assume that my problem stems from std::type_info comparison problems, so my question is basically: how do I go about making sure my RTTI info is all coming from the same place? I'm specifically referring to this snippet from the Wiki: "The best way to achieve that is to link both extension modules to a common shared library using the global model, and put the RTTI information there." I'm not sure how exactly I get all the relevant RTTI information into that third library. Just incase I'm completely off-course with my diagnosis of the problem, here's an example of what I'm talking about (this breaks in Linux with gcc 3.3.4): --- A.hpp --- struct A { A() {} virtual int foo() = 0; }; struct Factory { Factory() {} virtual A* make() = 0; }; --- A.cpp --- #include "A.hpp" --- B.hpp --- #include "A.hpp" struct B : public A { B() {} virtual int foo(); }; struct DerivedFactory : public Factory { DerivedFactory() {} virtual A* make(); }; --- B.cpp --- #include "B.hpp" int B::foo() { return 42; } A* DerivedFactory::make() { return new B; } --- A.pyste --- A = Class('A', 'A.hpp') Factory = Class('Factory', 'A.hpp') set_policy(Factory.make, return_value_policy(reference_existing_object)) --- B.pyste --- B = Class('B', 'B.hpp') DerivedFactory = Class('DerivedFactory', 'B.hpp') set_policy(DerivedFactory.make, return_value_policy(reference_existing_object)) And in Python:
import A, B x = B.DerivedFactory().make() x.foo() Traceback (most recent call last): File "<stdin>", line 1, in ? Boost.Python.ArgumentError: Python argument types in B.foo(B) did not match C++ signature: foo((anonymous namespace)::B_Wrapper {lvalue}) foo(B {lvalue}) x = B.B() x.foo() 42
Is there a way around this behavior, or is there just no hope for this pattern of shared library usage? Any help would be greatly appreciated, -- Dan Haffey
Dan Haffey <dan@theproverbial.com> writes:
I'm not sure if this is even the right place to post this question, but I'm having some trouble with inheritance across shared library boundaries. I've read the CrossExtensionModuleDependencies Wiki node, and I assume that my problem stems from std::type_info comparison problems, so my question is basically: how do I go about making sure my RTTI info is all coming from the same place?
I'm specifically referring to this snippet from the Wiki: "The best way to achieve that is to link both extension modules to a common shared library using the global model, and put the RTTI information there."
I'm not sure how exactly I get all the relevant RTTI information into that third library.
Put the base classes there. What it takes to generate the RTTI information will vary from compiler-to-compiler. Usually implementing one virtual function there is enough. Sometimes even a non-virtual function is sufficient. If your base classes have only pure virtual functions, you can still provide an implementation for one. If all else fails, you might try putting a dummy function in that library that uses dynamic_cast<Derived*>(some_base_ptr). Good luck! -- Dave Abrahams Boost Consulting www.boost-consulting.com
Dan Haffey <dan@theproverbial.com> writes:
Is there a way around this behavior, or is there just no hope for this pattern of shared library usage? Any help would be greatly appreciated,
It's hard for me to say anything useful without knowing: a. What code got generated by pyste for doing these bindings b. Where your shared library boundaries are. -- Dave Abrahams Boost Consulting www.boost-consulting.com
It's hard for me to say anything useful without knowing:
a. What code got generated by pyste for doing these bindings b. Where your shared library boundaries are.
Oh, sorry, I should have said something in this thread as well... it turned out my problems actually had less to do with linking than with forgetting to call Import in my Pyste files (there's a lesson in checking the actual Boost C++ calls if I've ever received one). Once I took care of that, I did actually run into some linking issues, but these were easily solved by putting the first virtual function of each of the offending classes into a common library as mentioned in the Wiki node. Sorry to waste your time, and thanks for your help and the great library! -- Dan Haffey
participants (3)
-
Dan Haffey -
Dan Haffey -
David Abrahams