Overloading methods in derived class
Hi, I’m wrapping a 3rd party library using boost.python and I’m bumping into a frustrating pattern. The library has derived classes which overload methods in their base class. They do properly expose the base class’ methods using “using”, but, when I try to wrap all of these derived classes, python doesn’t see the base class’ method through an instance of the derived class. Here’s an example: #include <boost/python.hpp> using namespace boost::python; struct A { virtual void foo(int a) {} virtual void bar(double b) {} }; struct B : A { virtual void foo(int a, double b) {} }; BOOST_PYTHON_MODULE(broken) { class_<A>(“A”) .def(“foo”, &A::foo) .def(“bar”, &A::bar) ; class_<B, bases<A> >(“B”) .def(“foo”, &B::foo) ; } Then in python: import broken a = broken.A() b = broken.B() a.foo(1) a.bar(2.0) b.foo(1,2.0) b.bar(2.0) b.foo(0) Running this I get (as you’ve probably already guessed): File “.../test.py”, line 11, in <module> b.foo(0) Boost.Python.ArgumentError: Python argument types in B.foo(B, int) Did not match C++ signature: foo(B {Value}, int, double) I’m not surprised by this behavior given python’s method resolution process. My question is whether there’s a good way to deal with this in boost.python so that I don’t have to add duplicate entries in sub-classes for methods I’ve already exposed in base classes. Thanks, Jeremy
On Thu, Aug 17, 2017 at 12:32 AM, Jeremy Mayes <jeremy.mayes@gmail.com> wrote:
File “.../test.py”, line 11, in <module> b.foo(0) Boost.Python.ArgumentError: Python argument types in B.foo(B, int) Did not match C++ signature: foo(B {Value}, int, double)
I’m not surprised by this behavior given python’s method resolution process. My question is whether there’s a good way to deal with this in boost.python so that I don’t have to add duplicate entries in sub-classes for methods I’ve already exposed in base classes.
Would you not have to declare the overloaded methods even if they were all part of the same class? It might even work exactly the same way, if the overloaded methods from the base class are not hidden.
participants (2)
-
Jeremy Mayes -
Stefan Ring