2016-08-12 11:50:00 +00:00
|
|
|
import pytest
|
2016-08-24 23:43:33 +00:00
|
|
|
import pybind11_tests
|
2016-08-12 11:50:00 +00:00
|
|
|
from pybind11_tests import ConstructorStats
|
|
|
|
|
|
|
|
|
|
|
|
def test_override(capture, msg):
|
|
|
|
from pybind11_tests import (ExampleVirt, runExampleVirt, runExampleVirtVirtual,
|
|
|
|
runExampleVirtBool)
|
|
|
|
|
|
|
|
class ExtendedExampleVirt(ExampleVirt):
|
|
|
|
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"
|
|
|
|
|
2016-08-12 11:50:00 +00:00
|
|
|
ex12 = ExampleVirt(10)
|
|
|
|
with capture:
|
|
|
|
assert 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:
|
|
|
|
runExampleVirtVirtual(ex12)
|
|
|
|
assert msg(excinfo.value) == 'Tried to call pure virtual function "ExampleVirt::pure_virtual"'
|
|
|
|
|
|
|
|
ex12p = ExtendedExampleVirt(10)
|
|
|
|
with capture:
|
|
|
|
assert runExampleVirt(ex12p, 20) == 32
|
|
|
|
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:
|
|
|
|
assert runExampleVirtBool(ex12p) is False
|
|
|
|
assert capture == "ExtendedExampleVirt::run_bool()"
|
|
|
|
with capture:
|
|
|
|
runExampleVirtVirtual(ex12p)
|
|
|
|
assert capture == "ExtendedExampleVirt::pure_virtual(): Hello world"
|
|
|
|
|
2016-09-08 18:49:43 +00:00
|
|
|
ex12p2 = ExtendedExampleVirt2(15)
|
|
|
|
with capture:
|
|
|
|
assert runExampleVirt(ex12p2, 50) == 68
|
|
|
|
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
|
|
|
|
2016-08-12 11:50:00 +00:00
|
|
|
cstats = ConstructorStats.get(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
|
|
|
|
|
|
|
|
|
2016-08-19 11:45:36 +00:00
|
|
|
def test_inheriting_repeat():
|
2016-08-12 11:50:00 +00:00
|
|
|
from pybind11_tests import A_Repeat, B_Repeat, C_Repeat, D_Repeat, A_Tpl, B_Tpl, C_Tpl, D_Tpl
|
|
|
|
|
2016-11-20 20:21:54 +00:00
|
|
|
class AR(A_Repeat):
|
2016-08-12 11:50:00 +00:00
|
|
|
def unlucky_number(self):
|
|
|
|
return 99
|
|
|
|
|
2016-11-20 20:21:54 +00:00
|
|
|
class AT(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
|
|
|
|
|
|
|
for obj in [B_Repeat(), 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
|
|
|
|
|
|
|
for obj in [C_Repeat(), 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
|
|
|
|
2016-11-20 20:21:54 +00:00
|
|
|
class CR(C_Repeat):
|
2016-08-12 11:50:00 +00:00
|
|
|
def lucky_number(self):
|
|
|
|
return C_Repeat.lucky_number(self) + 1.25
|
|
|
|
|
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
|
|
|
|
2016-11-20 20:21:54 +00:00
|
|
|
class CT(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
|
|
|
|
2016-11-20 20:21:54 +00:00
|
|
|
class DR(D_Repeat):
|
2016-08-12 11:50:00 +00:00
|
|
|
def unlucky_number(self):
|
|
|
|
return 123
|
|
|
|
|
|
|
|
def lucky_number(self):
|
|
|
|
return 42.0
|
|
|
|
|
|
|
|
for obj in [D_Repeat(), 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
|
|
|
|
2016-11-20 20:21:54 +00:00
|
|
|
class DT(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
|
|
|
|
|
2016-11-20 20:21:54 +00:00
|
|
|
class BT(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"
|
|
|
|
|
2016-08-12 11:50:00 +00:00
|
|
|
|
2016-12-16 14:00:46 +00:00
|
|
|
# PyPy: Reference count > 1 causes call with noncopyable instance
|
|
|
|
# to fail in ncv1.print_nc()
|
|
|
|
@pytest.unsupported_on_pypy
|
2016-08-25 00:20:35 +00:00
|
|
|
@pytest.mark.skipif(not hasattr(pybind11_tests, 'NCVirt'),
|
|
|
|
reason="NCVirt test broken on ICPC")
|
2016-08-19 11:45:36 +00:00
|
|
|
def test_move_support():
|
2016-08-12 11:50:00 +00:00
|
|
|
from pybind11_tests import NCVirt, NonCopyable, Movable
|
|
|
|
|
|
|
|
class NCVirtExt(NCVirt):
|
|
|
|
def get_noncopyable(self, a, b):
|
|
|
|
# Constructs and returns a new instance:
|
2016-08-25 00:20:35 +00:00
|
|
|
nc = NonCopyable(a * a, b * b)
|
2016-08-12 11:50:00 +00:00
|
|
|
return nc
|
|
|
|
|
|
|
|
def get_movable(self, a, b):
|
|
|
|
# Return a referenced copy
|
|
|
|
self.movable = Movable(a, b)
|
|
|
|
return self.movable
|
|
|
|
|
|
|
|
class NCVirtExt2(NCVirt):
|
|
|
|
def get_noncopyable(self, a, b):
|
|
|
|
# Keep a reference: this is going to throw an exception
|
|
|
|
self.nc = NonCopyable(a, b)
|
|
|
|
return self.nc
|
|
|
|
|
|
|
|
def get_movable(self, a, b):
|
|
|
|
# Return a new instance without storing it
|
|
|
|
return Movable(a, b)
|
|
|
|
|
|
|
|
ncv1 = NCVirtExt()
|
2016-08-19 11:45:36 +00:00
|
|
|
assert ncv1.print_nc(2, 3) == "36"
|
|
|
|
assert ncv1.print_movable(4, 5) == "9"
|
2016-08-12 11:50:00 +00:00
|
|
|
ncv2 = NCVirtExt2()
|
2016-08-19 11:45:36 +00:00
|
|
|
assert ncv2.print_movable(7, 7) == "14"
|
2016-08-12 11:50:00 +00:00
|
|
|
# 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(NonCopyable)
|
|
|
|
mv_stats = ConstructorStats.get(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
|