From jeremy.mayes at gmail.com Wed Aug 16 18:32:09 2017 From: jeremy.mayes at gmail.com (Jeremy Mayes) Date: Wed, 16 Aug 2017 22:32:09 +0000 Subject: [C++-sig] Overloading methods in derived class Message-ID: 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 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?) .def(?foo?, &A::foo) .def(?bar?, &A::bar) ; class_ >(?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 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefanrin at gmail.com Sat Aug 19 13:08:30 2017 From: stefanrin at gmail.com (Stefan Ring) Date: Sat, 19 Aug 2017 19:08:30 +0200 Subject: [C++-sig] Overloading methods in derived class In-Reply-To: References: Message-ID: On Thu, Aug 17, 2017 at 12:32 AM, Jeremy Mayes wrote: > File ?.../test.py?, line 11, in > 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.