2016-08-12 11:50:00 +00:00
|
|
|
import pytest
|
2017-06-22 21:42:11 +00:00
|
|
|
|
|
|
|
from pybind11_tests import virtual_functions as m
|
2016-08-12 11:50:00 +00:00
|
|
|
from pybind11_tests import ConstructorStats
|
|
|
|
|
|
|
|
|
|
|
|
def test_override(capture, msg):
|
2017-06-22 21:42:11 +00:00
|
|
|
class ExtendedExampleVirt(m.ExampleVirt):
|
2016-08-12 11:50:00 +00:00
|
|
|
def __init__(self, state):
|
|
|
|
super(ExtendedExampleVirt, self).__init__(state + 1)
|
|
|
|
self.data = "Hello world"
|
|
|
|
|
|
|
|
def run(self, value):
|
|
|
|
print('ExtendedExampleVirt::run(%i), calling parent..' % value)
|
|
|
|
return super(ExtendedExampleVirt, self).run(value + 1)
|
|
|
|
|
|
|
|
def run_bool(self):
|
|
|
|
print('ExtendedExampleVirt::run_bool()')
|
|
|
|
return False
|
|
|
|
|
2016-09-08 18:49:43 +00:00
|
|
|
def get_string1(self):
|
|
|
|
return "override1"
|
|
|
|
|
2016-08-12 11:50:00 +00:00
|
|
|
def pure_virtual(self):
|
|
|
|
print('ExtendedExampleVirt::pure_virtual(): %s' % self.data)
|
|
|
|
|
2016-09-08 18:49:43 +00:00
|
|
|
class ExtendedExampleVirt2(ExtendedExampleVirt):
|
|
|
|
def __init__(self, state):
|
|
|
|
super(ExtendedExampleVirt2, self).__init__(state + 1)
|
|
|
|
|
|
|
|
def get_string2(self):
|
|
|
|
return "override2"
|
|
|
|
|
2017-06-22 21:42:11 +00:00
|
|
|
ex12 = m.ExampleVirt(10)
|
2016-08-12 11:50:00 +00:00
|
|
|
with capture:
|
2017-06-22 21:42:11 +00:00
|
|
|
assert m.runExampleVirt(ex12, 20) == 30
|
2016-12-12 23:59:28 +00:00
|
|
|
assert capture == """
|
|
|
|
Original implementation of ExampleVirt::run(state=10, value=20, str1=default1, str2=default2)
|
|
|
|
""" # noqa: E501 line too long
|
2016-08-12 11:50:00 +00:00
|
|
|
|
|
|
|
with pytest.raises(RuntimeError) as excinfo:
|
2017-06-22 21:42:11 +00:00
|
|
|
m.runExampleVirtVirtual(ex12)
|
2016-08-12 11:50:00 +00:00
|
|
|
assert msg(excinfo.value) == 'Tried to call pure virtual function "ExampleVirt::pure_virtual"'
|
|
|
|
|
|
|
|
ex12p = ExtendedExampleVirt(10)
|
|
|
|
with capture:
|
2017-06-22 21:42:11 +00:00
|
|
|
assert m.runExampleVirt(ex12p, 20) == 32
|
2016-08-12 11:50:00 +00:00
|
|
|
assert capture == """
|
|
|
|
ExtendedExampleVirt::run(20), calling parent..
|
2016-09-08 18:49:43 +00:00
|
|
|
Original implementation of ExampleVirt::run(state=11, value=21, str1=override1, str2=default2)
|
2016-12-12 23:59:28 +00:00
|
|
|
""" # noqa: E501 line too long
|
2016-08-12 11:50:00 +00:00
|
|
|
with capture:
|
2017-06-22 21:42:11 +00:00
|
|
|
assert m.runExampleVirtBool(ex12p) is False
|
2016-08-12 11:50:00 +00:00
|
|
|
assert capture == "ExtendedExampleVirt::run_bool()"
|
|
|
|
with capture:
|
2017-06-22 21:42:11 +00:00
|
|
|
m.runExampleVirtVirtual(ex12p)
|
2016-08-12 11:50:00 +00:00
|
|
|
assert capture == "ExtendedExampleVirt::pure_virtual(): Hello world"
|
|
|
|
|
2016-09-08 18:49:43 +00:00
|
|
|
ex12p2 = ExtendedExampleVirt2(15)
|
|
|
|
with capture:
|
2017-06-22 21:42:11 +00:00
|
|
|
assert m.runExampleVirt(ex12p2, 50) == 68
|
2016-09-08 18:49:43 +00:00
|
|
|
assert capture == """
|
|
|
|
ExtendedExampleVirt::run(50), calling parent..
|
|
|
|
Original implementation of ExampleVirt::run(state=17, value=51, str1=override1, str2=override2)
|
2016-12-12 23:59:28 +00:00
|
|
|
""" # noqa: E501 line too long
|
2016-09-08 18:49:43 +00:00
|
|
|
|
2017-06-22 21:42:11 +00:00
|
|
|
cstats = ConstructorStats.get(m.ExampleVirt)
|
2016-09-08 18:49:43 +00:00
|
|
|
assert cstats.alive() == 3
|
|
|
|
del ex12, ex12p, ex12p2
|
2016-08-12 11:50:00 +00:00
|
|
|
assert cstats.alive() == 0
|
2016-09-08 18:49:43 +00:00
|
|
|
assert cstats.values() == ['10', '11', '17']
|
2016-08-12 11:50:00 +00:00
|
|
|
assert cstats.copy_constructions == 0
|
|
|
|
assert cstats.move_constructions >= 0
|
|
|
|
|
|
|
|
|
2017-06-22 21:42:11 +00:00
|
|
|
def test_alias_delay_initialization1(capture):
|
|
|
|
"""`A` only initializes its trampoline class when we inherit from it
|
|
|
|
|
|
|
|
If we just create and use an A instance directly, the trampoline initialization is
|
|
|
|
bypassed and we only initialize an A() instead (for performance reasons).
|
|
|
|
"""
|
|
|
|
class B(m.A):
|
|
|
|
def __init__(self):
|
|
|
|
super(B, self).__init__()
|
|
|
|
|
|
|
|
def f(self):
|
|
|
|
print("In python f()")
|
|
|
|
|
|
|
|
# C++ version
|
|
|
|
with capture:
|
|
|
|
a = m.A()
|
|
|
|
m.call_f(a)
|
|
|
|
del a
|
|
|
|
pytest.gc_collect()
|
|
|
|
assert capture == "A.f()"
|
|
|
|
|
|
|
|
# Python version
|
|
|
|
with capture:
|
|
|
|
b = B()
|
|
|
|
m.call_f(b)
|
|
|
|
del b
|
|
|
|
pytest.gc_collect()
|
|
|
|
assert capture == """
|
|
|
|
PyA.PyA()
|
|
|
|
PyA.f()
|
|
|
|
In python f()
|
|
|
|
PyA.~PyA()
|
|
|
|
"""
|
|
|
|
|
|
|
|
|
|
|
|
def test_alias_delay_initialization2(capture):
|
|
|
|
"""`A2`, unlike the above, is configured to always initialize the alias
|
|
|
|
|
|
|
|
While the extra initialization and extra class layer has small virtual dispatch
|
|
|
|
performance penalty, it also allows us to do more things with the trampoline
|
|
|
|
class such as defining local variables and performing construction/destruction.
|
|
|
|
"""
|
|
|
|
class B2(m.A2):
|
|
|
|
def __init__(self):
|
|
|
|
super(B2, self).__init__()
|
2016-08-12 11:50:00 +00:00
|
|
|
|
2017-06-22 21:42:11 +00:00
|
|
|
def f(self):
|
|
|
|
print("In python B2.f()")
|
|
|
|
|
|
|
|
# No python subclass version
|
|
|
|
with capture:
|
|
|
|
a2 = m.A2()
|
|
|
|
m.call_f(a2)
|
|
|
|
del a2
|
|
|
|
pytest.gc_collect()
|
Allow binding factory functions as constructors
This allows you to use:
cls.def(py::init(&factory_function));
where `factory_function` returns a pointer, holder, or value of the
class type (or a derived type). Various compile-time checks
(static_asserts) are performed to ensure the function is valid, and
various run-time type checks where necessary.
Some other details of this feature:
- The `py::init` name doesn't conflict with the templated no-argument
`py::init<...>()`, but keeps the naming consistent: the existing
templated, no-argument one wraps constructors, the no-template,
function-argument one wraps factory functions.
- If returning a CppClass (whether by value or pointer) when an CppAlias
is required (i.e. python-side inheritance and a declared alias), a
dynamic_cast to the alias is attempted (for the pointer version); if
it fails, or if returned by value, an Alias(Class &&) constructor
is invoked. If this constructor doesn't exist, a runtime error occurs.
- for holder returns when an alias is required, we try a dynamic_cast of
the wrapped pointer to the alias to see if it is already an alias
instance; if it isn't, we raise an error.
- `py::init(class_factory, alias_factory)` is also available that takes
two factories: the first is called when an alias is not needed, the
second when it is.
- Reimplement factory instance clearing. The previous implementation
failed under python-side multiple inheritance: *each* inherited
type's factory init would clear the instance instead of only setting
its own type value. The new implementation here clears just the
relevant value pointer.
- dealloc is updated to explicitly set the leftover value pointer to
nullptr and the `holder_constructed` flag to false so that it can be
used to clear preallocated value without needing to rebuild the
instance internals data.
- Added various tests to test out new allocation/deallocation code.
- With preallocation now done lazily, init factory holders can
completely avoid the extra overhead of needing an extra
allocation/deallocation.
- Updated documentation to make factory constructors the default
advanced constructor style.
- If an `__init__` is called a second time, we have two choices: we can
throw away the first instance, replacing it with the second; or we can
ignore the second call. The latter is slightly easier, so do that.
2017-06-13 01:52:48 +00:00
|
|
|
a3 = m.A2(1)
|
|
|
|
m.call_f(a3)
|
|
|
|
del a3
|
|
|
|
pytest.gc_collect()
|
2017-06-22 21:42:11 +00:00
|
|
|
assert capture == """
|
|
|
|
PyA2.PyA2()
|
|
|
|
PyA2.f()
|
|
|
|
A2.f()
|
|
|
|
PyA2.~PyA2()
|
Allow binding factory functions as constructors
This allows you to use:
cls.def(py::init(&factory_function));
where `factory_function` returns a pointer, holder, or value of the
class type (or a derived type). Various compile-time checks
(static_asserts) are performed to ensure the function is valid, and
various run-time type checks where necessary.
Some other details of this feature:
- The `py::init` name doesn't conflict with the templated no-argument
`py::init<...>()`, but keeps the naming consistent: the existing
templated, no-argument one wraps constructors, the no-template,
function-argument one wraps factory functions.
- If returning a CppClass (whether by value or pointer) when an CppAlias
is required (i.e. python-side inheritance and a declared alias), a
dynamic_cast to the alias is attempted (for the pointer version); if
it fails, or if returned by value, an Alias(Class &&) constructor
is invoked. If this constructor doesn't exist, a runtime error occurs.
- for holder returns when an alias is required, we try a dynamic_cast of
the wrapped pointer to the alias to see if it is already an alias
instance; if it isn't, we raise an error.
- `py::init(class_factory, alias_factory)` is also available that takes
two factories: the first is called when an alias is not needed, the
second when it is.
- Reimplement factory instance clearing. The previous implementation
failed under python-side multiple inheritance: *each* inherited
type's factory init would clear the instance instead of only setting
its own type value. The new implementation here clears just the
relevant value pointer.
- dealloc is updated to explicitly set the leftover value pointer to
nullptr and the `holder_constructed` flag to false so that it can be
used to clear preallocated value without needing to rebuild the
instance internals data.
- Added various tests to test out new allocation/deallocation code.
- With preallocation now done lazily, init factory holders can
completely avoid the extra overhead of needing an extra
allocation/deallocation.
- Updated documentation to make factory constructors the default
advanced constructor style.
- If an `__init__` is called a second time, we have two choices: we can
throw away the first instance, replacing it with the second; or we can
ignore the second call. The latter is slightly easier, so do that.
2017-06-13 01:52:48 +00:00
|
|
|
PyA2.PyA2()
|
|
|
|
PyA2.f()
|
|
|
|
A2.f()
|
|
|
|
PyA2.~PyA2()
|
2017-06-22 21:42:11 +00:00
|
|
|
"""
|
|
|
|
|
|
|
|
# Python subclass version
|
|
|
|
with capture:
|
|
|
|
b2 = B2()
|
|
|
|
m.call_f(b2)
|
|
|
|
del b2
|
|
|
|
pytest.gc_collect()
|
|
|
|
assert capture == """
|
|
|
|
PyA2.PyA2()
|
|
|
|
PyA2.f()
|
|
|
|
In python B2.f()
|
|
|
|
PyA2.~PyA2()
|
|
|
|
"""
|
|
|
|
|
|
|
|
|
Update all remaining tests to new test styles
This udpates all the remaining tests to the new test suite code and
comment styles started in #898. For the most part, the test coverage
here is unchanged, with a few minor exceptions as noted below.
- test_constants_and_functions: this adds more overload tests with
overloads with different number of arguments for more comprehensive
overload_cast testing. The test style conversion broke the overload
tests under MSVC 2015, prompting the additional tests while looking
for a workaround.
- test_eigen: this dropped the unused functions `get_cm_corners` and
`get_cm_corners_const`--these same tests were duplicates of the same
things provided (and used) via ReturnTester methods.
- test_opaque_types: this test had a hidden dependence on ExampleMandA
which is now fixed by using the global UserType which suffices for the
relevant test.
- test_methods_and_attributes: this required some additions to UserType
to make it usable as a replacement for the test's previous SimpleType:
UserType gained a value mutator, and the `value` property is not
mutable (it was previously readonly). Some overload tests were also
added to better test overload_cast (as described above).
- test_numpy_array: removed the untemplated mutate_data/mutate_data_t:
the templated versions with an empty parameter pack expand to the same
thing.
- test_stl: this was already mostly in the new style; this just tweaks
things a bit, localizing a class, and adding some missing
`// test_whatever` comments.
- test_virtual_functions: like `test_stl`, this was mostly in the new
test style already, but needed some `// test_whatever` comments.
This commit also moves the inherited virtual example code to the end
of the file, after the main set of tests (since it is less important
than the other tests, and rather length); it also got renamed to
`test_inherited_virtuals` (from `test_inheriting_repeat`) because it
tests both inherited virtual approaches, not just the repeat approach.
2017-07-25 20:47:36 +00:00
|
|
|
# PyPy: Reference count > 1 causes call with noncopyable instance
|
|
|
|
# to fail in ncv1.print_nc()
|
|
|
|
@pytest.unsupported_on_pypy
|
|
|
|
@pytest.mark.skipif(not hasattr(m, "NCVirt"), reason="NCVirt test broken on ICPC")
|
|
|
|
def test_move_support():
|
|
|
|
class NCVirtExt(m.NCVirt):
|
|
|
|
def get_noncopyable(self, a, b):
|
|
|
|
# Constructs and returns a new instance:
|
|
|
|
nc = m.NonCopyable(a * a, b * b)
|
|
|
|
return nc
|
|
|
|
|
|
|
|
def get_movable(self, a, b):
|
|
|
|
# Return a referenced copy
|
|
|
|
self.movable = m.Movable(a, b)
|
|
|
|
return self.movable
|
|
|
|
|
|
|
|
class NCVirtExt2(m.NCVirt):
|
|
|
|
def get_noncopyable(self, a, b):
|
|
|
|
# Keep a reference: this is going to throw an exception
|
|
|
|
self.nc = m.NonCopyable(a, b)
|
|
|
|
return self.nc
|
|
|
|
|
|
|
|
def get_movable(self, a, b):
|
|
|
|
# Return a new instance without storing it
|
|
|
|
return m.Movable(a, b)
|
|
|
|
|
|
|
|
ncv1 = NCVirtExt()
|
|
|
|
assert ncv1.print_nc(2, 3) == "36"
|
|
|
|
assert ncv1.print_movable(4, 5) == "9"
|
|
|
|
ncv2 = NCVirtExt2()
|
|
|
|
assert ncv2.print_movable(7, 7) == "14"
|
|
|
|
# Don't check the exception message here because it differs under debug/non-debug mode
|
|
|
|
with pytest.raises(RuntimeError):
|
|
|
|
ncv2.print_nc(9, 9)
|
|
|
|
|
|
|
|
nc_stats = ConstructorStats.get(m.NonCopyable)
|
|
|
|
mv_stats = ConstructorStats.get(m.Movable)
|
|
|
|
assert nc_stats.alive() == 1
|
|
|
|
assert mv_stats.alive() == 1
|
|
|
|
del ncv1, ncv2
|
|
|
|
assert nc_stats.alive() == 0
|
|
|
|
assert mv_stats.alive() == 0
|
|
|
|
assert nc_stats.values() == ['4', '9', '9', '9']
|
|
|
|
assert mv_stats.values() == ['4', '5', '7', '7']
|
|
|
|
assert nc_stats.copy_constructions == 0
|
|
|
|
assert mv_stats.copy_constructions == 1
|
|
|
|
assert nc_stats.move_constructions >= 0
|
|
|
|
assert mv_stats.move_constructions >= 0
|
|
|
|
|
|
|
|
|
|
|
|
def test_dispatch_issue(msg):
|
|
|
|
"""#159: virtual function dispatch has problems with similar-named functions"""
|
|
|
|
class PyClass1(m.DispatchIssue):
|
|
|
|
def dispatch(self):
|
|
|
|
return "Yay.."
|
|
|
|
|
|
|
|
class PyClass2(m.DispatchIssue):
|
|
|
|
def dispatch(self):
|
|
|
|
with pytest.raises(RuntimeError) as excinfo:
|
|
|
|
super(PyClass2, self).dispatch()
|
|
|
|
assert msg(excinfo.value) == 'Tried to call pure virtual function "Base::dispatch"'
|
|
|
|
|
|
|
|
p = PyClass1()
|
|
|
|
return m.dispatch_issue_go(p)
|
|
|
|
|
|
|
|
b = PyClass2()
|
|
|
|
assert m.dispatch_issue_go(b) == "Yay.."
|
|
|
|
|
|
|
|
|
|
|
|
def test_override_ref():
|
|
|
|
"""#392/397: overridding reference-returning functions"""
|
|
|
|
o = m.OverrideTest("asdf")
|
|
|
|
|
|
|
|
# Not allowed (see associated .cpp comment)
|
|
|
|
# i = o.str_ref()
|
|
|
|
# assert o.str_ref() == "asdf"
|
|
|
|
assert o.str_value() == "asdf"
|
|
|
|
|
|
|
|
assert o.A_value().value == "hi"
|
|
|
|
a = o.A_ref()
|
|
|
|
assert a.value == "hi"
|
|
|
|
a.value = "bye"
|
|
|
|
assert a.value == "bye"
|
|
|
|
|
|
|
|
|
|
|
|
def test_inherited_virtuals():
|
2017-06-22 21:42:11 +00:00
|
|
|
class AR(m.A_Repeat):
|
2016-08-12 11:50:00 +00:00
|
|
|
def unlucky_number(self):
|
|
|
|
return 99
|
|
|
|
|
2017-06-22 21:42:11 +00:00
|
|
|
class AT(m.A_Tpl):
|
2016-08-12 11:50:00 +00:00
|
|
|
def unlucky_number(self):
|
|
|
|
return 999
|
|
|
|
|
2016-11-20 20:21:54 +00:00
|
|
|
obj = AR()
|
2016-08-19 11:45:36 +00:00
|
|
|
assert obj.say_something(3) == "hihihi"
|
2016-08-12 11:50:00 +00:00
|
|
|
assert obj.unlucky_number() == 99
|
Fix template trampoline overload lookup failure
Problem
=======
The template trampoline pattern documented in PR #322 has a problem with
virtual method overloads in intermediate classes in the inheritance
chain between the trampoline class and the base class.
For example, consider the following inheritance structure, where `B` is
the actual class, `PyB<B>` is the trampoline class, and `PyA<B>` is an
intermediate class adding A's methods into the trampoline:
PyB<B> -> PyA<B> -> B -> A
Suppose PyA<B> has a method `some_method()` with a PYBIND11_OVERLOAD in
it to overload the virtual `A::some_method()`. If a Python class `C` is
defined that inherits from the pybind11-registered `B` and tries to
provide an overriding `some_method()`, the PYBIND11_OVERLOADs declared
in PyA<B> fails to find this overloaded method, and thus never invoke it
(or, if pure virtual and not overridden in PyB<B>, raises an exception).
This happens because the base (internal) `PYBIND11_OVERLOAD_INT` macro
simply calls `get_overload(this, name)`; `get_overload()` then uses the
inferred type of `this` to do a type lookup in `registered_types_cpp`.
This is where it fails: `this` will be a `PyA<B> *`, but `PyA<B>` is
neither the base type (`B`) nor the trampoline type (`PyB<B>`). As a
result, the overload fails and we get a failed overload lookup.
The fix
=======
The fix is relatively simple: we can cast `this` passed to
`get_overload()` to a `const B *`, which lets get_overload look up the
correct class. Since trampoline classes should be derived from `B`
classes anyway, this cast should be perfectly safe.
This does require adding the class name as an argument to the
PYBIND11_OVERLOAD_INT macro, but leaves the public macro signatures
unchanged.
2016-08-29 22:16:46 +00:00
|
|
|
assert obj.say_everything() == "hi 99"
|
2016-08-12 11:50:00 +00:00
|
|
|
|
2016-11-20 20:21:54 +00:00
|
|
|
obj = AT()
|
2016-08-19 11:45:36 +00:00
|
|
|
assert obj.say_something(3) == "hihihi"
|
2016-08-12 11:50:00 +00:00
|
|
|
assert obj.unlucky_number() == 999
|
Fix template trampoline overload lookup failure
Problem
=======
The template trampoline pattern documented in PR #322 has a problem with
virtual method overloads in intermediate classes in the inheritance
chain between the trampoline class and the base class.
For example, consider the following inheritance structure, where `B` is
the actual class, `PyB<B>` is the trampoline class, and `PyA<B>` is an
intermediate class adding A's methods into the trampoline:
PyB<B> -> PyA<B> -> B -> A
Suppose PyA<B> has a method `some_method()` with a PYBIND11_OVERLOAD in
it to overload the virtual `A::some_method()`. If a Python class `C` is
defined that inherits from the pybind11-registered `B` and tries to
provide an overriding `some_method()`, the PYBIND11_OVERLOADs declared
in PyA<B> fails to find this overloaded method, and thus never invoke it
(or, if pure virtual and not overridden in PyB<B>, raises an exception).
This happens because the base (internal) `PYBIND11_OVERLOAD_INT` macro
simply calls `get_overload(this, name)`; `get_overload()` then uses the
inferred type of `this` to do a type lookup in `registered_types_cpp`.
This is where it fails: `this` will be a `PyA<B> *`, but `PyA<B>` is
neither the base type (`B`) nor the trampoline type (`PyB<B>`). As a
result, the overload fails and we get a failed overload lookup.
The fix
=======
The fix is relatively simple: we can cast `this` passed to
`get_overload()` to a `const B *`, which lets get_overload look up the
correct class. Since trampoline classes should be derived from `B`
classes anyway, this cast should be perfectly safe.
This does require adding the class name as an argument to the
PYBIND11_OVERLOAD_INT macro, but leaves the public macro signatures
unchanged.
2016-08-29 22:16:46 +00:00
|
|
|
assert obj.say_everything() == "hi 999"
|
2016-08-12 11:50:00 +00:00
|
|
|
|
2017-06-22 21:42:11 +00:00
|
|
|
for obj in [m.B_Repeat(), m.B_Tpl()]:
|
2016-08-19 11:45:36 +00:00
|
|
|
assert obj.say_something(3) == "B says hi 3 times"
|
2016-08-12 11:50:00 +00:00
|
|
|
assert obj.unlucky_number() == 13
|
|
|
|
assert obj.lucky_number() == 7.0
|
Fix template trampoline overload lookup failure
Problem
=======
The template trampoline pattern documented in PR #322 has a problem with
virtual method overloads in intermediate classes in the inheritance
chain between the trampoline class and the base class.
For example, consider the following inheritance structure, where `B` is
the actual class, `PyB<B>` is the trampoline class, and `PyA<B>` is an
intermediate class adding A's methods into the trampoline:
PyB<B> -> PyA<B> -> B -> A
Suppose PyA<B> has a method `some_method()` with a PYBIND11_OVERLOAD in
it to overload the virtual `A::some_method()`. If a Python class `C` is
defined that inherits from the pybind11-registered `B` and tries to
provide an overriding `some_method()`, the PYBIND11_OVERLOADs declared
in PyA<B> fails to find this overloaded method, and thus never invoke it
(or, if pure virtual and not overridden in PyB<B>, raises an exception).
This happens because the base (internal) `PYBIND11_OVERLOAD_INT` macro
simply calls `get_overload(this, name)`; `get_overload()` then uses the
inferred type of `this` to do a type lookup in `registered_types_cpp`.
This is where it fails: `this` will be a `PyA<B> *`, but `PyA<B>` is
neither the base type (`B`) nor the trampoline type (`PyB<B>`). As a
result, the overload fails and we get a failed overload lookup.
The fix
=======
The fix is relatively simple: we can cast `this` passed to
`get_overload()` to a `const B *`, which lets get_overload look up the
correct class. Since trampoline classes should be derived from `B`
classes anyway, this cast should be perfectly safe.
This does require adding the class name as an argument to the
PYBIND11_OVERLOAD_INT macro, but leaves the public macro signatures
unchanged.
2016-08-29 22:16:46 +00:00
|
|
|
assert obj.say_everything() == "B says hi 1 times 13"
|
2016-08-12 11:50:00 +00:00
|
|
|
|
2017-06-22 21:42:11 +00:00
|
|
|
for obj in [m.C_Repeat(), m.C_Tpl()]:
|
2016-08-19 11:45:36 +00:00
|
|
|
assert obj.say_something(3) == "B says hi 3 times"
|
2016-08-12 11:50:00 +00:00
|
|
|
assert obj.unlucky_number() == 4444
|
|
|
|
assert obj.lucky_number() == 888.0
|
Fix template trampoline overload lookup failure
Problem
=======
The template trampoline pattern documented in PR #322 has a problem with
virtual method overloads in intermediate classes in the inheritance
chain between the trampoline class and the base class.
For example, consider the following inheritance structure, where `B` is
the actual class, `PyB<B>` is the trampoline class, and `PyA<B>` is an
intermediate class adding A's methods into the trampoline:
PyB<B> -> PyA<B> -> B -> A
Suppose PyA<B> has a method `some_method()` with a PYBIND11_OVERLOAD in
it to overload the virtual `A::some_method()`. If a Python class `C` is
defined that inherits from the pybind11-registered `B` and tries to
provide an overriding `some_method()`, the PYBIND11_OVERLOADs declared
in PyA<B> fails to find this overloaded method, and thus never invoke it
(or, if pure virtual and not overridden in PyB<B>, raises an exception).
This happens because the base (internal) `PYBIND11_OVERLOAD_INT` macro
simply calls `get_overload(this, name)`; `get_overload()` then uses the
inferred type of `this` to do a type lookup in `registered_types_cpp`.
This is where it fails: `this` will be a `PyA<B> *`, but `PyA<B>` is
neither the base type (`B`) nor the trampoline type (`PyB<B>`). As a
result, the overload fails and we get a failed overload lookup.
The fix
=======
The fix is relatively simple: we can cast `this` passed to
`get_overload()` to a `const B *`, which lets get_overload look up the
correct class. Since trampoline classes should be derived from `B`
classes anyway, this cast should be perfectly safe.
This does require adding the class name as an argument to the
PYBIND11_OVERLOAD_INT macro, but leaves the public macro signatures
unchanged.
2016-08-29 22:16:46 +00:00
|
|
|
assert obj.say_everything() == "B says hi 1 times 4444"
|
2016-08-12 11:50:00 +00:00
|
|
|
|
2017-06-22 21:42:11 +00:00
|
|
|
class CR(m.C_Repeat):
|
2016-08-12 11:50:00 +00:00
|
|
|
def lucky_number(self):
|
2017-06-22 21:42:11 +00:00
|
|
|
return m.C_Repeat.lucky_number(self) + 1.25
|
2016-08-12 11:50:00 +00:00
|
|
|
|
2016-11-20 20:21:54 +00:00
|
|
|
obj = CR()
|
2016-08-19 11:45:36 +00:00
|
|
|
assert obj.say_something(3) == "B says hi 3 times"
|
2016-08-12 11:50:00 +00:00
|
|
|
assert obj.unlucky_number() == 4444
|
|
|
|
assert obj.lucky_number() == 889.25
|
Fix template trampoline overload lookup failure
Problem
=======
The template trampoline pattern documented in PR #322 has a problem with
virtual method overloads in intermediate classes in the inheritance
chain between the trampoline class and the base class.
For example, consider the following inheritance structure, where `B` is
the actual class, `PyB<B>` is the trampoline class, and `PyA<B>` is an
intermediate class adding A's methods into the trampoline:
PyB<B> -> PyA<B> -> B -> A
Suppose PyA<B> has a method `some_method()` with a PYBIND11_OVERLOAD in
it to overload the virtual `A::some_method()`. If a Python class `C` is
defined that inherits from the pybind11-registered `B` and tries to
provide an overriding `some_method()`, the PYBIND11_OVERLOADs declared
in PyA<B> fails to find this overloaded method, and thus never invoke it
(or, if pure virtual and not overridden in PyB<B>, raises an exception).
This happens because the base (internal) `PYBIND11_OVERLOAD_INT` macro
simply calls `get_overload(this, name)`; `get_overload()` then uses the
inferred type of `this` to do a type lookup in `registered_types_cpp`.
This is where it fails: `this` will be a `PyA<B> *`, but `PyA<B>` is
neither the base type (`B`) nor the trampoline type (`PyB<B>`). As a
result, the overload fails and we get a failed overload lookup.
The fix
=======
The fix is relatively simple: we can cast `this` passed to
`get_overload()` to a `const B *`, which lets get_overload look up the
correct class. Since trampoline classes should be derived from `B`
classes anyway, this cast should be perfectly safe.
This does require adding the class name as an argument to the
PYBIND11_OVERLOAD_INT macro, but leaves the public macro signatures
unchanged.
2016-08-29 22:16:46 +00:00
|
|
|
assert obj.say_everything() == "B says hi 1 times 4444"
|
2016-08-12 11:50:00 +00:00
|
|
|
|
2017-06-22 21:42:11 +00:00
|
|
|
class CT(m.C_Tpl):
|
2016-08-12 11:50:00 +00:00
|
|
|
pass
|
|
|
|
|
2016-11-20 20:21:54 +00:00
|
|
|
obj = CT()
|
2016-08-19 11:45:36 +00:00
|
|
|
assert obj.say_something(3) == "B says hi 3 times"
|
2016-08-12 11:50:00 +00:00
|
|
|
assert obj.unlucky_number() == 4444
|
|
|
|
assert obj.lucky_number() == 888.0
|
Fix template trampoline overload lookup failure
Problem
=======
The template trampoline pattern documented in PR #322 has a problem with
virtual method overloads in intermediate classes in the inheritance
chain between the trampoline class and the base class.
For example, consider the following inheritance structure, where `B` is
the actual class, `PyB<B>` is the trampoline class, and `PyA<B>` is an
intermediate class adding A's methods into the trampoline:
PyB<B> -> PyA<B> -> B -> A
Suppose PyA<B> has a method `some_method()` with a PYBIND11_OVERLOAD in
it to overload the virtual `A::some_method()`. If a Python class `C` is
defined that inherits from the pybind11-registered `B` and tries to
provide an overriding `some_method()`, the PYBIND11_OVERLOADs declared
in PyA<B> fails to find this overloaded method, and thus never invoke it
(or, if pure virtual and not overridden in PyB<B>, raises an exception).
This happens because the base (internal) `PYBIND11_OVERLOAD_INT` macro
simply calls `get_overload(this, name)`; `get_overload()` then uses the
inferred type of `this` to do a type lookup in `registered_types_cpp`.
This is where it fails: `this` will be a `PyA<B> *`, but `PyA<B>` is
neither the base type (`B`) nor the trampoline type (`PyB<B>`). As a
result, the overload fails and we get a failed overload lookup.
The fix
=======
The fix is relatively simple: we can cast `this` passed to
`get_overload()` to a `const B *`, which lets get_overload look up the
correct class. Since trampoline classes should be derived from `B`
classes anyway, this cast should be perfectly safe.
This does require adding the class name as an argument to the
PYBIND11_OVERLOAD_INT macro, but leaves the public macro signatures
unchanged.
2016-08-29 22:16:46 +00:00
|
|
|
assert obj.say_everything() == "B says hi 1 times 4444"
|
2016-08-12 11:50:00 +00:00
|
|
|
|
2016-11-20 20:21:54 +00:00
|
|
|
class CCR(CR):
|
2016-08-12 11:50:00 +00:00
|
|
|
def lucky_number(self):
|
2016-11-20 20:21:54 +00:00
|
|
|
return CR.lucky_number(self) * 10
|
2016-08-12 11:50:00 +00:00
|
|
|
|
2016-11-20 20:21:54 +00:00
|
|
|
obj = CCR()
|
2016-08-19 11:45:36 +00:00
|
|
|
assert obj.say_something(3) == "B says hi 3 times"
|
2016-08-12 11:50:00 +00:00
|
|
|
assert obj.unlucky_number() == 4444
|
|
|
|
assert obj.lucky_number() == 8892.5
|
Fix template trampoline overload lookup failure
Problem
=======
The template trampoline pattern documented in PR #322 has a problem with
virtual method overloads in intermediate classes in the inheritance
chain between the trampoline class and the base class.
For example, consider the following inheritance structure, where `B` is
the actual class, `PyB<B>` is the trampoline class, and `PyA<B>` is an
intermediate class adding A's methods into the trampoline:
PyB<B> -> PyA<B> -> B -> A
Suppose PyA<B> has a method `some_method()` with a PYBIND11_OVERLOAD in
it to overload the virtual `A::some_method()`. If a Python class `C` is
defined that inherits from the pybind11-registered `B` and tries to
provide an overriding `some_method()`, the PYBIND11_OVERLOADs declared
in PyA<B> fails to find this overloaded method, and thus never invoke it
(or, if pure virtual and not overridden in PyB<B>, raises an exception).
This happens because the base (internal) `PYBIND11_OVERLOAD_INT` macro
simply calls `get_overload(this, name)`; `get_overload()` then uses the
inferred type of `this` to do a type lookup in `registered_types_cpp`.
This is where it fails: `this` will be a `PyA<B> *`, but `PyA<B>` is
neither the base type (`B`) nor the trampoline type (`PyB<B>`). As a
result, the overload fails and we get a failed overload lookup.
The fix
=======
The fix is relatively simple: we can cast `this` passed to
`get_overload()` to a `const B *`, which lets get_overload look up the
correct class. Since trampoline classes should be derived from `B`
classes anyway, this cast should be perfectly safe.
This does require adding the class name as an argument to the
PYBIND11_OVERLOAD_INT macro, but leaves the public macro signatures
unchanged.
2016-08-29 22:16:46 +00:00
|
|
|
assert obj.say_everything() == "B says hi 1 times 4444"
|
2016-08-12 11:50:00 +00:00
|
|
|
|
2016-11-20 20:21:54 +00:00
|
|
|
class CCT(CT):
|
2016-08-12 11:50:00 +00:00
|
|
|
def lucky_number(self):
|
2016-11-20 20:21:54 +00:00
|
|
|
return CT.lucky_number(self) * 1000
|
2016-08-12 11:50:00 +00:00
|
|
|
|
2016-11-20 20:21:54 +00:00
|
|
|
obj = CCT()
|
2016-08-19 11:45:36 +00:00
|
|
|
assert obj.say_something(3) == "B says hi 3 times"
|
2016-08-12 11:50:00 +00:00
|
|
|
assert obj.unlucky_number() == 4444
|
|
|
|
assert obj.lucky_number() == 888000.0
|
Fix template trampoline overload lookup failure
Problem
=======
The template trampoline pattern documented in PR #322 has a problem with
virtual method overloads in intermediate classes in the inheritance
chain between the trampoline class and the base class.
For example, consider the following inheritance structure, where `B` is
the actual class, `PyB<B>` is the trampoline class, and `PyA<B>` is an
intermediate class adding A's methods into the trampoline:
PyB<B> -> PyA<B> -> B -> A
Suppose PyA<B> has a method `some_method()` with a PYBIND11_OVERLOAD in
it to overload the virtual `A::some_method()`. If a Python class `C` is
defined that inherits from the pybind11-registered `B` and tries to
provide an overriding `some_method()`, the PYBIND11_OVERLOADs declared
in PyA<B> fails to find this overloaded method, and thus never invoke it
(or, if pure virtual and not overridden in PyB<B>, raises an exception).
This happens because the base (internal) `PYBIND11_OVERLOAD_INT` macro
simply calls `get_overload(this, name)`; `get_overload()` then uses the
inferred type of `this` to do a type lookup in `registered_types_cpp`.
This is where it fails: `this` will be a `PyA<B> *`, but `PyA<B>` is
neither the base type (`B`) nor the trampoline type (`PyB<B>`). As a
result, the overload fails and we get a failed overload lookup.
The fix
=======
The fix is relatively simple: we can cast `this` passed to
`get_overload()` to a `const B *`, which lets get_overload look up the
correct class. Since trampoline classes should be derived from `B`
classes anyway, this cast should be perfectly safe.
This does require adding the class name as an argument to the
PYBIND11_OVERLOAD_INT macro, but leaves the public macro signatures
unchanged.
2016-08-29 22:16:46 +00:00
|
|
|
assert obj.say_everything() == "B says hi 1 times 4444"
|
2016-08-12 11:50:00 +00:00
|
|
|
|
2017-06-22 21:42:11 +00:00
|
|
|
class DR(m.D_Repeat):
|
2016-08-12 11:50:00 +00:00
|
|
|
def unlucky_number(self):
|
|
|
|
return 123
|
|
|
|
|
|
|
|
def lucky_number(self):
|
|
|
|
return 42.0
|
|
|
|
|
2017-06-22 21:42:11 +00:00
|
|
|
for obj in [m.D_Repeat(), m.D_Tpl()]:
|
2016-08-19 11:45:36 +00:00
|
|
|
assert obj.say_something(3) == "B says hi 3 times"
|
2016-08-12 11:50:00 +00:00
|
|
|
assert obj.unlucky_number() == 4444
|
|
|
|
assert obj.lucky_number() == 888.0
|
Fix template trampoline overload lookup failure
Problem
=======
The template trampoline pattern documented in PR #322 has a problem with
virtual method overloads in intermediate classes in the inheritance
chain between the trampoline class and the base class.
For example, consider the following inheritance structure, where `B` is
the actual class, `PyB<B>` is the trampoline class, and `PyA<B>` is an
intermediate class adding A's methods into the trampoline:
PyB<B> -> PyA<B> -> B -> A
Suppose PyA<B> has a method `some_method()` with a PYBIND11_OVERLOAD in
it to overload the virtual `A::some_method()`. If a Python class `C` is
defined that inherits from the pybind11-registered `B` and tries to
provide an overriding `some_method()`, the PYBIND11_OVERLOADs declared
in PyA<B> fails to find this overloaded method, and thus never invoke it
(or, if pure virtual and not overridden in PyB<B>, raises an exception).
This happens because the base (internal) `PYBIND11_OVERLOAD_INT` macro
simply calls `get_overload(this, name)`; `get_overload()` then uses the
inferred type of `this` to do a type lookup in `registered_types_cpp`.
This is where it fails: `this` will be a `PyA<B> *`, but `PyA<B>` is
neither the base type (`B`) nor the trampoline type (`PyB<B>`). As a
result, the overload fails and we get a failed overload lookup.
The fix
=======
The fix is relatively simple: we can cast `this` passed to
`get_overload()` to a `const B *`, which lets get_overload look up the
correct class. Since trampoline classes should be derived from `B`
classes anyway, this cast should be perfectly safe.
This does require adding the class name as an argument to the
PYBIND11_OVERLOAD_INT macro, but leaves the public macro signatures
unchanged.
2016-08-29 22:16:46 +00:00
|
|
|
assert obj.say_everything() == "B says hi 1 times 4444"
|
2016-08-12 11:50:00 +00:00
|
|
|
|
2016-11-20 20:21:54 +00:00
|
|
|
obj = DR()
|
2016-08-19 11:45:36 +00:00
|
|
|
assert obj.say_something(3) == "B says hi 3 times"
|
2016-08-12 11:50:00 +00:00
|
|
|
assert obj.unlucky_number() == 123
|
|
|
|
assert obj.lucky_number() == 42.0
|
Fix template trampoline overload lookup failure
Problem
=======
The template trampoline pattern documented in PR #322 has a problem with
virtual method overloads in intermediate classes in the inheritance
chain between the trampoline class and the base class.
For example, consider the following inheritance structure, where `B` is
the actual class, `PyB<B>` is the trampoline class, and `PyA<B>` is an
intermediate class adding A's methods into the trampoline:
PyB<B> -> PyA<B> -> B -> A
Suppose PyA<B> has a method `some_method()` with a PYBIND11_OVERLOAD in
it to overload the virtual `A::some_method()`. If a Python class `C` is
defined that inherits from the pybind11-registered `B` and tries to
provide an overriding `some_method()`, the PYBIND11_OVERLOADs declared
in PyA<B> fails to find this overloaded method, and thus never invoke it
(or, if pure virtual and not overridden in PyB<B>, raises an exception).
This happens because the base (internal) `PYBIND11_OVERLOAD_INT` macro
simply calls `get_overload(this, name)`; `get_overload()` then uses the
inferred type of `this` to do a type lookup in `registered_types_cpp`.
This is where it fails: `this` will be a `PyA<B> *`, but `PyA<B>` is
neither the base type (`B`) nor the trampoline type (`PyB<B>`). As a
result, the overload fails and we get a failed overload lookup.
The fix
=======
The fix is relatively simple: we can cast `this` passed to
`get_overload()` to a `const B *`, which lets get_overload look up the
correct class. Since trampoline classes should be derived from `B`
classes anyway, this cast should be perfectly safe.
This does require adding the class name as an argument to the
PYBIND11_OVERLOAD_INT macro, but leaves the public macro signatures
unchanged.
2016-08-29 22:16:46 +00:00
|
|
|
assert obj.say_everything() == "B says hi 1 times 123"
|
2016-08-12 11:50:00 +00:00
|
|
|
|
2017-06-22 21:42:11 +00:00
|
|
|
class DT(m.D_Tpl):
|
2016-08-12 11:50:00 +00:00
|
|
|
def say_something(self, times):
|
2016-11-20 20:21:54 +00:00
|
|
|
return "DT says:" + (' quack' * times)
|
2016-08-12 11:50:00 +00:00
|
|
|
|
|
|
|
def unlucky_number(self):
|
|
|
|
return 1234
|
|
|
|
|
|
|
|
def lucky_number(self):
|
|
|
|
return -4.25
|
|
|
|
|
2016-11-20 20:21:54 +00:00
|
|
|
obj = DT()
|
|
|
|
assert obj.say_something(3) == "DT says: quack quack quack"
|
2016-08-12 11:50:00 +00:00
|
|
|
assert obj.unlucky_number() == 1234
|
|
|
|
assert obj.lucky_number() == -4.25
|
2016-11-20 20:21:54 +00:00
|
|
|
assert obj.say_everything() == "DT says: quack 1234"
|
Fix template trampoline overload lookup failure
Problem
=======
The template trampoline pattern documented in PR #322 has a problem with
virtual method overloads in intermediate classes in the inheritance
chain between the trampoline class and the base class.
For example, consider the following inheritance structure, where `B` is
the actual class, `PyB<B>` is the trampoline class, and `PyA<B>` is an
intermediate class adding A's methods into the trampoline:
PyB<B> -> PyA<B> -> B -> A
Suppose PyA<B> has a method `some_method()` with a PYBIND11_OVERLOAD in
it to overload the virtual `A::some_method()`. If a Python class `C` is
defined that inherits from the pybind11-registered `B` and tries to
provide an overriding `some_method()`, the PYBIND11_OVERLOADs declared
in PyA<B> fails to find this overloaded method, and thus never invoke it
(or, if pure virtual and not overridden in PyB<B>, raises an exception).
This happens because the base (internal) `PYBIND11_OVERLOAD_INT` macro
simply calls `get_overload(this, name)`; `get_overload()` then uses the
inferred type of `this` to do a type lookup in `registered_types_cpp`.
This is where it fails: `this` will be a `PyA<B> *`, but `PyA<B>` is
neither the base type (`B`) nor the trampoline type (`PyB<B>`). As a
result, the overload fails and we get a failed overload lookup.
The fix
=======
The fix is relatively simple: we can cast `this` passed to
`get_overload()` to a `const B *`, which lets get_overload look up the
correct class. Since trampoline classes should be derived from `B`
classes anyway, this cast should be perfectly safe.
This does require adding the class name as an argument to the
PYBIND11_OVERLOAD_INT macro, but leaves the public macro signatures
unchanged.
2016-08-29 22:16:46 +00:00
|
|
|
|
2016-11-20 20:21:54 +00:00
|
|
|
class DT2(DT):
|
Fix template trampoline overload lookup failure
Problem
=======
The template trampoline pattern documented in PR #322 has a problem with
virtual method overloads in intermediate classes in the inheritance
chain between the trampoline class and the base class.
For example, consider the following inheritance structure, where `B` is
the actual class, `PyB<B>` is the trampoline class, and `PyA<B>` is an
intermediate class adding A's methods into the trampoline:
PyB<B> -> PyA<B> -> B -> A
Suppose PyA<B> has a method `some_method()` with a PYBIND11_OVERLOAD in
it to overload the virtual `A::some_method()`. If a Python class `C` is
defined that inherits from the pybind11-registered `B` and tries to
provide an overriding `some_method()`, the PYBIND11_OVERLOADs declared
in PyA<B> fails to find this overloaded method, and thus never invoke it
(or, if pure virtual and not overridden in PyB<B>, raises an exception).
This happens because the base (internal) `PYBIND11_OVERLOAD_INT` macro
simply calls `get_overload(this, name)`; `get_overload()` then uses the
inferred type of `this` to do a type lookup in `registered_types_cpp`.
This is where it fails: `this` will be a `PyA<B> *`, but `PyA<B>` is
neither the base type (`B`) nor the trampoline type (`PyB<B>`). As a
result, the overload fails and we get a failed overload lookup.
The fix
=======
The fix is relatively simple: we can cast `this` passed to
`get_overload()` to a `const B *`, which lets get_overload look up the
correct class. Since trampoline classes should be derived from `B`
classes anyway, this cast should be perfectly safe.
This does require adding the class name as an argument to the
PYBIND11_OVERLOAD_INT macro, but leaves the public macro signatures
unchanged.
2016-08-29 22:16:46 +00:00
|
|
|
def say_something(self, times):
|
2016-11-20 20:21:54 +00:00
|
|
|
return "DT2: " + ('QUACK' * times)
|
Fix template trampoline overload lookup failure
Problem
=======
The template trampoline pattern documented in PR #322 has a problem with
virtual method overloads in intermediate classes in the inheritance
chain between the trampoline class and the base class.
For example, consider the following inheritance structure, where `B` is
the actual class, `PyB<B>` is the trampoline class, and `PyA<B>` is an
intermediate class adding A's methods into the trampoline:
PyB<B> -> PyA<B> -> B -> A
Suppose PyA<B> has a method `some_method()` with a PYBIND11_OVERLOAD in
it to overload the virtual `A::some_method()`. If a Python class `C` is
defined that inherits from the pybind11-registered `B` and tries to
provide an overriding `some_method()`, the PYBIND11_OVERLOADs declared
in PyA<B> fails to find this overloaded method, and thus never invoke it
(or, if pure virtual and not overridden in PyB<B>, raises an exception).
This happens because the base (internal) `PYBIND11_OVERLOAD_INT` macro
simply calls `get_overload(this, name)`; `get_overload()` then uses the
inferred type of `this` to do a type lookup in `registered_types_cpp`.
This is where it fails: `this` will be a `PyA<B> *`, but `PyA<B>` is
neither the base type (`B`) nor the trampoline type (`PyB<B>`). As a
result, the overload fails and we get a failed overload lookup.
The fix
=======
The fix is relatively simple: we can cast `this` passed to
`get_overload()` to a `const B *`, which lets get_overload look up the
correct class. Since trampoline classes should be derived from `B`
classes anyway, this cast should be perfectly safe.
This does require adding the class name as an argument to the
PYBIND11_OVERLOAD_INT macro, but leaves the public macro signatures
unchanged.
2016-08-29 22:16:46 +00:00
|
|
|
|
|
|
|
def unlucky_number(self):
|
|
|
|
return -3
|
|
|
|
|
2017-06-22 21:42:11 +00:00
|
|
|
class BT(m.B_Tpl):
|
Fix template trampoline overload lookup failure
Problem
=======
The template trampoline pattern documented in PR #322 has a problem with
virtual method overloads in intermediate classes in the inheritance
chain between the trampoline class and the base class.
For example, consider the following inheritance structure, where `B` is
the actual class, `PyB<B>` is the trampoline class, and `PyA<B>` is an
intermediate class adding A's methods into the trampoline:
PyB<B> -> PyA<B> -> B -> A
Suppose PyA<B> has a method `some_method()` with a PYBIND11_OVERLOAD in
it to overload the virtual `A::some_method()`. If a Python class `C` is
defined that inherits from the pybind11-registered `B` and tries to
provide an overriding `some_method()`, the PYBIND11_OVERLOADs declared
in PyA<B> fails to find this overloaded method, and thus never invoke it
(or, if pure virtual and not overridden in PyB<B>, raises an exception).
This happens because the base (internal) `PYBIND11_OVERLOAD_INT` macro
simply calls `get_overload(this, name)`; `get_overload()` then uses the
inferred type of `this` to do a type lookup in `registered_types_cpp`.
This is where it fails: `this` will be a `PyA<B> *`, but `PyA<B>` is
neither the base type (`B`) nor the trampoline type (`PyB<B>`). As a
result, the overload fails and we get a failed overload lookup.
The fix
=======
The fix is relatively simple: we can cast `this` passed to
`get_overload()` to a `const B *`, which lets get_overload look up the
correct class. Since trampoline classes should be derived from `B`
classes anyway, this cast should be perfectly safe.
This does require adding the class name as an argument to the
PYBIND11_OVERLOAD_INT macro, but leaves the public macro signatures
unchanged.
2016-08-29 22:16:46 +00:00
|
|
|
def say_something(self, times):
|
2016-11-20 20:21:54 +00:00
|
|
|
return "BT" * times
|
|
|
|
|
Fix template trampoline overload lookup failure
Problem
=======
The template trampoline pattern documented in PR #322 has a problem with
virtual method overloads in intermediate classes in the inheritance
chain between the trampoline class and the base class.
For example, consider the following inheritance structure, where `B` is
the actual class, `PyB<B>` is the trampoline class, and `PyA<B>` is an
intermediate class adding A's methods into the trampoline:
PyB<B> -> PyA<B> -> B -> A
Suppose PyA<B> has a method `some_method()` with a PYBIND11_OVERLOAD in
it to overload the virtual `A::some_method()`. If a Python class `C` is
defined that inherits from the pybind11-registered `B` and tries to
provide an overriding `some_method()`, the PYBIND11_OVERLOADs declared
in PyA<B> fails to find this overloaded method, and thus never invoke it
(or, if pure virtual and not overridden in PyB<B>, raises an exception).
This happens because the base (internal) `PYBIND11_OVERLOAD_INT` macro
simply calls `get_overload(this, name)`; `get_overload()` then uses the
inferred type of `this` to do a type lookup in `registered_types_cpp`.
This is where it fails: `this` will be a `PyA<B> *`, but `PyA<B>` is
neither the base type (`B`) nor the trampoline type (`PyB<B>`). As a
result, the overload fails and we get a failed overload lookup.
The fix
=======
The fix is relatively simple: we can cast `this` passed to
`get_overload()` to a `const B *`, which lets get_overload look up the
correct class. Since trampoline classes should be derived from `B`
classes anyway, this cast should be perfectly safe.
This does require adding the class name as an argument to the
PYBIND11_OVERLOAD_INT macro, but leaves the public macro signatures
unchanged.
2016-08-29 22:16:46 +00:00
|
|
|
def unlucky_number(self):
|
|
|
|
return -7
|
2016-11-20 20:21:54 +00:00
|
|
|
|
Fix template trampoline overload lookup failure
Problem
=======
The template trampoline pattern documented in PR #322 has a problem with
virtual method overloads in intermediate classes in the inheritance
chain between the trampoline class and the base class.
For example, consider the following inheritance structure, where `B` is
the actual class, `PyB<B>` is the trampoline class, and `PyA<B>` is an
intermediate class adding A's methods into the trampoline:
PyB<B> -> PyA<B> -> B -> A
Suppose PyA<B> has a method `some_method()` with a PYBIND11_OVERLOAD in
it to overload the virtual `A::some_method()`. If a Python class `C` is
defined that inherits from the pybind11-registered `B` and tries to
provide an overriding `some_method()`, the PYBIND11_OVERLOADs declared
in PyA<B> fails to find this overloaded method, and thus never invoke it
(or, if pure virtual and not overridden in PyB<B>, raises an exception).
This happens because the base (internal) `PYBIND11_OVERLOAD_INT` macro
simply calls `get_overload(this, name)`; `get_overload()` then uses the
inferred type of `this` to do a type lookup in `registered_types_cpp`.
This is where it fails: `this` will be a `PyA<B> *`, but `PyA<B>` is
neither the base type (`B`) nor the trampoline type (`PyB<B>`). As a
result, the overload fails and we get a failed overload lookup.
The fix
=======
The fix is relatively simple: we can cast `this` passed to
`get_overload()` to a `const B *`, which lets get_overload look up the
correct class. Since trampoline classes should be derived from `B`
classes anyway, this cast should be perfectly safe.
This does require adding the class name as an argument to the
PYBIND11_OVERLOAD_INT macro, but leaves the public macro signatures
unchanged.
2016-08-29 22:16:46 +00:00
|
|
|
def lucky_number(self):
|
|
|
|
return -1.375
|
|
|
|
|
2016-11-20 20:21:54 +00:00
|
|
|
obj = BT()
|
|
|
|
assert obj.say_something(3) == "BTBTBT"
|
Fix template trampoline overload lookup failure
Problem
=======
The template trampoline pattern documented in PR #322 has a problem with
virtual method overloads in intermediate classes in the inheritance
chain between the trampoline class and the base class.
For example, consider the following inheritance structure, where `B` is
the actual class, `PyB<B>` is the trampoline class, and `PyA<B>` is an
intermediate class adding A's methods into the trampoline:
PyB<B> -> PyA<B> -> B -> A
Suppose PyA<B> has a method `some_method()` with a PYBIND11_OVERLOAD in
it to overload the virtual `A::some_method()`. If a Python class `C` is
defined that inherits from the pybind11-registered `B` and tries to
provide an overriding `some_method()`, the PYBIND11_OVERLOADs declared
in PyA<B> fails to find this overloaded method, and thus never invoke it
(or, if pure virtual and not overridden in PyB<B>, raises an exception).
This happens because the base (internal) `PYBIND11_OVERLOAD_INT` macro
simply calls `get_overload(this, name)`; `get_overload()` then uses the
inferred type of `this` to do a type lookup in `registered_types_cpp`.
This is where it fails: `this` will be a `PyA<B> *`, but `PyA<B>` is
neither the base type (`B`) nor the trampoline type (`PyB<B>`). As a
result, the overload fails and we get a failed overload lookup.
The fix
=======
The fix is relatively simple: we can cast `this` passed to
`get_overload()` to a `const B *`, which lets get_overload look up the
correct class. Since trampoline classes should be derived from `B`
classes anyway, this cast should be perfectly safe.
This does require adding the class name as an argument to the
PYBIND11_OVERLOAD_INT macro, but leaves the public macro signatures
unchanged.
2016-08-29 22:16:46 +00:00
|
|
|
assert obj.unlucky_number() == -7
|
|
|
|
assert obj.lucky_number() == -1.375
|
2016-11-20 20:21:54 +00:00
|
|
|
assert obj.say_everything() == "BT -7"
|