Zengtudor
/
pybind11
mirror of https://github.com/pybind/pybind11.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
pybind11/example/example-virtual-functions.ref

98 lines
1.6 KiB
Plaintext
Raw Normal View History

Rename examples files, as per #288 This renames example files from `exampleN` to `example-description`. Specifically, the following renaming is applied: example1 -> example-methods-and-attributes example2 -> example-python-types example3 -> example-operator-overloading example4 -> example-constants-and-functions example5 -> example-callbacks (*) example6 -> example-sequence-and-iterators example7 -> example-buffers example8 -> example-custom-ref-counting example9 -> example-modules example10 -> example-numpy-vectorize example11 -> example-arg-keywords-and-defaults example12 -> example-virtual-functions example13 -> example-keep-alive example14 -> example-opaque-types example15 -> example-pickling example16 -> example-inheritance example17 -> example-stl-binders example18 -> example-eval example19 -> example-custom-exceptions * the inheritance parts of example5 are moved into example-inheritance (previously example16), and the remainder is left as example-callbacks. This commit also renames the internal variables ("Example1", "Example2", "Example4", etc.) into non-numeric names ("ExampleMandA", "ExamplePythonTypes", "ExampleWithEnum", etc.) to correspond to the file renaming. The order of tests is preserved, but this can easily be changed if there is some more natural ordering by updating the list in examples/CMakeLists.txt.
2016-07-18 20:43:18 +00:00
Constructing ExampleVirt..
Original implementation of ExampleVirt::run(state=10, value=20)
30
Caught expected exception: Tried to call pure virtual function "ExampleVirt::pure_virtual"
Constructing ExampleVirt..
ExtendedExampleVirt::run(20), calling parent..
Original implementation of ExampleVirt::run(state=11, value=21)
32
ExtendedExampleVirt::run_bool()
False
ExtendedExampleVirt::pure_virtual(): Hello world
Added advanced doc section on virtual methods + inheritance As discussed in #320. The adds a documentation block that mentions that the trampoline classes must provide overrides for both the classes' own virtual methods *and* any inherited virtual methods. It also provides a templated solution to avoiding method duplication. The example includes a third method (only mentioned in the "see also" section of the documentation addition), using multiple inheritance. While this approach works, and avoids code generation in deep hierarchies, it is intrusive by requiring that the wrapped classes use virtual inheritance, which itself is more instrusive if any of the virtual base classes need anything other than default constructors. As per the discussion in #320, it is kept as an example, but not suggested in the documentation.
2016-08-05 21:02:33 +00:00
VI_AR:
hihihi
Unlucky = 99
VI_AT:
hihihi
Unlucky = 999
B_Repeat:
B says hi 3 times
Unlucky = 13
Lucky = 7.00
B_Tpl:
B says hi 3 times
Unlucky = 13
Lucky = 7.00
C_Repeat:
B says hi 3 times
Unlucky = 4444
Lucky = 888.00
C_Tpl:
B says hi 3 times
Unlucky = 4444
Lucky = 888.00
VI_CR:
B says hi 3 times
Unlucky = 4444
Lucky = 889.25
VI_CT:
B says hi 3 times
Unlucky = 4444
Lucky = 888.00
VI_CCR:
B says hi 3 times
Unlucky = 4444
Lucky = 8892.50
VI_CCT:
B says hi 3 times
Unlucky = 4444
Lucky = 888000.00
D_Repeat:
B says hi 3 times
Unlucky = 4444
Lucky = 888.00
D_Tpl:
B says hi 3 times
Unlucky = 4444
Lucky = 888.00
VI_DR:
B says hi 3 times
Unlucky = 123
Lucky = 42.00
VI_DT:
VI_DT says: quack quack quack
Unlucky = 1234
Lucky = -4.25
Move support for return values of called Python functions Currently pybind11 always translates values returned by Python functions invoked from C++ code by copying, even when moving is feasible--and, more importantly, even when moving is required. The first, and relatively minor, concern is that moving may be considerably more efficient for some types. The second problem, however, is more serious: there's currently no way python code can return a non-copyable type to C++ code. I ran into this while trying to add a PYBIND11_OVERLOAD of a virtual method that returns just such a type: it simply fails to compile because this: overload = ... overload(args).template cast<ret_type>(); involves a copy: overload(args) returns an object instance, and the invoked object::cast() loads the returned value, then returns a copy of the loaded value. We can, however, safely move that returned value *if* the object has the only reference to it (i.e. if ref_count() == 1) and the object is itself temporary (i.e. if it's an rvalue). This commit does that by adding an rvalue-qualified object::cast() method that allows the returned value to be move-constructed out of the stored instance when feasible. This basically comes down to three cases: - For objects that are movable but not copyable, we always try the move, with a runtime exception raised if this would involve moving a value with multiple references. - When the type is both movable and non-trivially copyable, the move happens only if the invoked object has a ref_count of 1, otherwise the object is copied. (Trivially copyable types are excluded from this case because they are typically just collections of primitive types, which can be copied just as easily as they can be moved.) - Non-movable and trivially copy constructible objects are simply copied. This also adds examples to example-virtual-functions that shows both a non-copyable object and a movable/copyable object in action: the former raises an exception if returned while holding a reference, the latter invokes a move constructor if unreferenced, or a copy constructor if referenced. Basically this allows code such as: class MyClass(Pybind11Class): def somemethod(self, whatever): mt = MovableType(whatever) # ... return mt which allows the MovableType instance to be returned to the C++ code via its move constructor. Of course if you attempt to violate this by doing something like: self.value = MovableType(whatever) return self.value you get an exception--but right now, the pybind11-side of that code won't compile at all.
2016-07-22 01:31:05 +00:00
2^2 * 3^2 =
NonCopyable destructor @ 0x1a6c3f0; value = (null)
36
NonCopyable destructor @ 0x7ffc6d1fbaa8; value = 36
4 + 5 =
Movable @ 0x7ffc6d1fbacc copy constructor
9
Movable destructor @ 0x7ffc6d1fbacc; value = 9
7 + 7 =
Movable @ 0x7ffc6d1fbacc move constructor
Movable destructor @ 0x1a6c4d0; value = 14
14
Movable destructor @ 0x7ffc6d1fbacc; value = 14
Caught expected exception
NonCopyable destructor @ 0x29a64b0; value = 81
Movable destructor @ 0x1a6c410; value = 9
Rename examples files, as per #288 This renames example files from `exampleN` to `example-description`. Specifically, the following renaming is applied: example1 -> example-methods-and-attributes example2 -> example-python-types example3 -> example-operator-overloading example4 -> example-constants-and-functions example5 -> example-callbacks (*) example6 -> example-sequence-and-iterators example7 -> example-buffers example8 -> example-custom-ref-counting example9 -> example-modules example10 -> example-numpy-vectorize example11 -> example-arg-keywords-and-defaults example12 -> example-virtual-functions example13 -> example-keep-alive example14 -> example-opaque-types example15 -> example-pickling example16 -> example-inheritance example17 -> example-stl-binders example18 -> example-eval example19 -> example-custom-exceptions * the inheritance parts of example5 are moved into example-inheritance (previously example16), and the remainder is left as example-callbacks. This commit also renames the internal variables ("Example1", "Example2", "Example4", etc.) into non-numeric names ("ExampleMandA", "ExamplePythonTypes", "ExampleWithEnum", etc.) to correspond to the file renaming. The order of tests is preserved, but this can easily be changed if there is some more natural ordering by updating the list in examples/CMakeLists.txt.
2016-07-18 20:43:18 +00:00
Destructing ExampleVirt..
Destructing ExampleVirt..