2015-10-01 14:46:03 +00:00
|
|
|
/*
|
2016-08-12 11:50:00 +00:00
|
|
|
tests/test_virtual_functions.cpp -- overriding virtual functions from Python
|
2015-10-01 14:46:03 +00:00
|
|
|
|
2016-04-17 18:21:41 +00:00
|
|
|
Copyright (c) 2016 Wenzel Jakob <wenzel.jakob@epfl.ch>
|
2015-10-01 14:46:03 +00:00
|
|
|
|
|
|
|
All rights reserved. Use of this source code is governed by a
|
|
|
|
BSD-style license that can be found in the LICENSE file.
|
|
|
|
*/
|
|
|
|
|
2016-08-12 11:50:00 +00:00
|
|
|
#include "pybind11_tests.h"
|
|
|
|
#include "constructor_stats.h"
|
2015-10-15 16:13:33 +00:00
|
|
|
#include <pybind11/functional.h>
|
2015-10-01 14:46:03 +00:00
|
|
|
|
|
|
|
/* This is an example class that we'll want to be able to extend from Python */
|
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
|
|
|
class ExampleVirt {
|
2015-10-01 14:46:03 +00:00
|
|
|
public:
|
Improve constructor/destructor tracking
This commit rewrites the examples that look for constructor/destructor
calls to do so via static variable tracking rather than output parsing.
The added ConstructorStats class provides methods to keep track of
constructors and destructors, number of default/copy/move constructors,
and number of copy/move assignments. It also provides a mechanism for
storing values (e.g. for value construction), and then allows all of
this to be checked at the end of a test by getting the statistics for a
C++ (or python mapping) class.
By not relying on the precise pattern of constructions/destructions,
but rather simply ensuring that every construction is matched with a
destruction on the same object, we ensure that everything that gets
created also gets destroyed as expected.
This replaces all of the various "std::cout << whatever" code in
constructors/destructors with
`print_created(this)`/`print_destroyed(this)`/etc. functions which
provide similar output, but now has a unified format across the
different examples, including a new ### prefix that makes mixed example
output and lifecycle events easier to distinguish.
With this change, relaxed mode is no longer needed, which enables
testing for proper destruction under MSVC, and under any other compiler
that generates code calling extra constructors, or optimizes away any
constructors. GCC/clang are used as the baseline for move
constructors; the tests are adapted to allow more move constructors to
be evoked (but other types are constructors much have matching counts).
This commit also disables output buffering of tests, as the buffering
sometimes results in C++ output ending up in the middle of python
output (or vice versa), depending on the OS/python version.
2016-08-07 17:05:26 +00:00
|
|
|
ExampleVirt(int state) : state(state) { print_created(this, state); }
|
|
|
|
ExampleVirt(const ExampleVirt &e) : state(e.state) { print_copy_created(this); }
|
|
|
|
ExampleVirt(ExampleVirt &&e) : state(e.state) { print_move_created(this); e.state = 0; }
|
|
|
|
~ExampleVirt() { print_destroyed(this); }
|
2015-10-01 14:46:03 +00:00
|
|
|
|
|
|
|
virtual int run(int value) {
|
2016-09-06 22:50:10 +00:00
|
|
|
py::print("Original implementation of "
|
2016-09-08 18:49:43 +00:00
|
|
|
"ExampleVirt::run(state={}, value={}, str1={}, str2={})"_s.format(state, value, get_string1(), *get_string2()));
|
2015-10-01 14:46:03 +00:00
|
|
|
return state + value;
|
|
|
|
}
|
|
|
|
|
2016-02-23 21:41:07 +00:00
|
|
|
virtual bool run_bool() = 0;
|
2015-10-01 14:46:03 +00:00
|
|
|
virtual void pure_virtual() = 0;
|
2016-09-08 18:49:43 +00:00
|
|
|
|
|
|
|
// Returning a reference/pointer to a type converted from python (numbers, strings, etc.) is a
|
|
|
|
// bit trickier, because the actual int& or std::string& or whatever only exists temporarily, so
|
|
|
|
// we have to handle it specially in the trampoline class (see below).
|
|
|
|
virtual const std::string &get_string1() { return str1; }
|
|
|
|
virtual const std::string *get_string2() { return &str2; }
|
|
|
|
|
2015-10-01 14:46:03 +00:00
|
|
|
private:
|
|
|
|
int state;
|
2016-09-08 18:49:43 +00:00
|
|
|
const std::string str1{"default1"}, str2{"default2"};
|
2015-10-01 14:46:03 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
/* This is a wrapper class that must be generated */
|
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
|
|
|
class PyExampleVirt : public ExampleVirt {
|
2015-10-01 14:46:03 +00:00
|
|
|
public:
|
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
|
|
|
using ExampleVirt::ExampleVirt; /* Inherit constructors */
|
2015-10-01 14:46:03 +00:00
|
|
|
|
2016-09-08 18:47:05 +00:00
|
|
|
int run(int value) override {
|
2015-10-01 14:46:03 +00:00
|
|
|
/* Generate wrapping code that enables native function overloading */
|
2015-10-18 14:48:30 +00:00
|
|
|
PYBIND11_OVERLOAD(
|
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
|
|
|
int, /* Return type */
|
|
|
|
ExampleVirt, /* Parent class */
|
|
|
|
run, /* Name of function */
|
|
|
|
value /* Argument(s) */
|
2015-10-01 14:46:03 +00:00
|
|
|
);
|
|
|
|
}
|
|
|
|
|
2016-09-08 18:47:05 +00:00
|
|
|
bool run_bool() override {
|
2016-02-23 21:41:07 +00:00
|
|
|
PYBIND11_OVERLOAD_PURE(
|
2016-04-18 08:34:27 +00:00
|
|
|
bool, /* Return type */
|
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
|
|
|
ExampleVirt, /* Parent class */
|
2016-04-18 08:34:27 +00:00
|
|
|
run_bool, /* Name of function */
|
|
|
|
/* This function has no arguments. The trailing comma
|
|
|
|
in the previous line is needed for some compilers */
|
2016-02-23 21:41:07 +00:00
|
|
|
);
|
|
|
|
}
|
|
|
|
|
2016-09-08 18:47:05 +00:00
|
|
|
void pure_virtual() override {
|
2015-10-18 14:48:30 +00:00
|
|
|
PYBIND11_OVERLOAD_PURE(
|
2015-10-01 14:46:03 +00:00
|
|
|
void, /* Return type */
|
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
|
|
|
ExampleVirt, /* Parent class */
|
2016-04-18 08:34:27 +00:00
|
|
|
pure_virtual, /* Name of function */
|
|
|
|
/* This function has no arguments. The trailing comma
|
|
|
|
in the previous line is needed for some compilers */
|
2015-10-01 14:46:03 +00:00
|
|
|
);
|
|
|
|
}
|
2016-09-08 18:49:43 +00:00
|
|
|
|
|
|
|
// We can return reference types for compatibility with C++ virtual interfaces that do so, but
|
|
|
|
// note they have some significant limitations (see the documentation).
|
|
|
|
const std::string &get_string1() override {
|
|
|
|
PYBIND11_OVERLOAD(
|
|
|
|
const std::string &, /* Return type */
|
|
|
|
ExampleVirt, /* Parent class */
|
|
|
|
get_string1, /* Name of function */
|
|
|
|
/* (no arguments) */
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
|
|
|
const std::string *get_string2() override {
|
|
|
|
PYBIND11_OVERLOAD(
|
|
|
|
const std::string *, /* Return type */
|
|
|
|
ExampleVirt, /* Parent class */
|
|
|
|
get_string2, /* Name of function */
|
|
|
|
/* (no arguments) */
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
2015-10-01 14:46:03 +00:00
|
|
|
};
|
|
|
|
|
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
|
|
|
class NonCopyable {
|
|
|
|
public:
|
Improve constructor/destructor tracking
This commit rewrites the examples that look for constructor/destructor
calls to do so via static variable tracking rather than output parsing.
The added ConstructorStats class provides methods to keep track of
constructors and destructors, number of default/copy/move constructors,
and number of copy/move assignments. It also provides a mechanism for
storing values (e.g. for value construction), and then allows all of
this to be checked at the end of a test by getting the statistics for a
C++ (or python mapping) class.
By not relying on the precise pattern of constructions/destructions,
but rather simply ensuring that every construction is matched with a
destruction on the same object, we ensure that everything that gets
created also gets destroyed as expected.
This replaces all of the various "std::cout << whatever" code in
constructors/destructors with
`print_created(this)`/`print_destroyed(this)`/etc. functions which
provide similar output, but now has a unified format across the
different examples, including a new ### prefix that makes mixed example
output and lifecycle events easier to distinguish.
With this change, relaxed mode is no longer needed, which enables
testing for proper destruction under MSVC, and under any other compiler
that generates code calling extra constructors, or optimizes away any
constructors. GCC/clang are used as the baseline for move
constructors; the tests are adapted to allow more move constructors to
be evoked (but other types are constructors much have matching counts).
This commit also disables output buffering of tests, as the buffering
sometimes results in C++ output ending up in the middle of python
output (or vice versa), depending on the OS/python version.
2016-08-07 17:05:26 +00:00
|
|
|
NonCopyable(int a, int b) : value{new int(a*b)} { print_created(this, a, b); }
|
|
|
|
NonCopyable(NonCopyable &&o) { value = std::move(o.value); print_move_created(this); }
|
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
|
|
|
NonCopyable(const NonCopyable &) = delete;
|
|
|
|
NonCopyable() = delete;
|
|
|
|
void operator=(const NonCopyable &) = delete;
|
|
|
|
void operator=(NonCopyable &&) = delete;
|
|
|
|
std::string get_value() const {
|
|
|
|
if (value) return std::to_string(*value); else return "(null)";
|
|
|
|
}
|
Improve constructor/destructor tracking
This commit rewrites the examples that look for constructor/destructor
calls to do so via static variable tracking rather than output parsing.
The added ConstructorStats class provides methods to keep track of
constructors and destructors, number of default/copy/move constructors,
and number of copy/move assignments. It also provides a mechanism for
storing values (e.g. for value construction), and then allows all of
this to be checked at the end of a test by getting the statistics for a
C++ (or python mapping) class.
By not relying on the precise pattern of constructions/destructions,
but rather simply ensuring that every construction is matched with a
destruction on the same object, we ensure that everything that gets
created also gets destroyed as expected.
This replaces all of the various "std::cout << whatever" code in
constructors/destructors with
`print_created(this)`/`print_destroyed(this)`/etc. functions which
provide similar output, but now has a unified format across the
different examples, including a new ### prefix that makes mixed example
output and lifecycle events easier to distinguish.
With this change, relaxed mode is no longer needed, which enables
testing for proper destruction under MSVC, and under any other compiler
that generates code calling extra constructors, or optimizes away any
constructors. GCC/clang are used as the baseline for move
constructors; the tests are adapted to allow more move constructors to
be evoked (but other types are constructors much have matching counts).
This commit also disables output buffering of tests, as the buffering
sometimes results in C++ output ending up in the middle of python
output (or vice versa), depending on the OS/python version.
2016-08-07 17:05:26 +00:00
|
|
|
~NonCopyable() { print_destroyed(this); }
|
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
|
|
|
|
|
|
|
private:
|
|
|
|
std::unique_ptr<int> value;
|
|
|
|
};
|
|
|
|
|
|
|
|
// This is like the above, but is both copy and movable. In effect this means it should get moved
|
|
|
|
// when it is not referenced elsewhere, but copied if it is still referenced.
|
|
|
|
class Movable {
|
|
|
|
public:
|
Improve constructor/destructor tracking
This commit rewrites the examples that look for constructor/destructor
calls to do so via static variable tracking rather than output parsing.
The added ConstructorStats class provides methods to keep track of
constructors and destructors, number of default/copy/move constructors,
and number of copy/move assignments. It also provides a mechanism for
storing values (e.g. for value construction), and then allows all of
this to be checked at the end of a test by getting the statistics for a
C++ (or python mapping) class.
By not relying on the precise pattern of constructions/destructions,
but rather simply ensuring that every construction is matched with a
destruction on the same object, we ensure that everything that gets
created also gets destroyed as expected.
This replaces all of the various "std::cout << whatever" code in
constructors/destructors with
`print_created(this)`/`print_destroyed(this)`/etc. functions which
provide similar output, but now has a unified format across the
different examples, including a new ### prefix that makes mixed example
output and lifecycle events easier to distinguish.
With this change, relaxed mode is no longer needed, which enables
testing for proper destruction under MSVC, and under any other compiler
that generates code calling extra constructors, or optimizes away any
constructors. GCC/clang are used as the baseline for move
constructors; the tests are adapted to allow more move constructors to
be evoked (but other types are constructors much have matching counts).
This commit also disables output buffering of tests, as the buffering
sometimes results in C++ output ending up in the middle of python
output (or vice versa), depending on the OS/python version.
2016-08-07 17:05:26 +00:00
|
|
|
Movable(int a, int b) : value{a+b} { print_created(this, a, b); }
|
|
|
|
Movable(const Movable &m) { value = m.value; print_copy_created(this); }
|
|
|
|
Movable(Movable &&m) { value = std::move(m.value); print_move_created(this); }
|
2016-08-19 11:45:36 +00:00
|
|
|
std::string get_value() const { return std::to_string(value); }
|
Improve constructor/destructor tracking
This commit rewrites the examples that look for constructor/destructor
calls to do so via static variable tracking rather than output parsing.
The added ConstructorStats class provides methods to keep track of
constructors and destructors, number of default/copy/move constructors,
and number of copy/move assignments. It also provides a mechanism for
storing values (e.g. for value construction), and then allows all of
this to be checked at the end of a test by getting the statistics for a
C++ (or python mapping) class.
By not relying on the precise pattern of constructions/destructions,
but rather simply ensuring that every construction is matched with a
destruction on the same object, we ensure that everything that gets
created also gets destroyed as expected.
This replaces all of the various "std::cout << whatever" code in
constructors/destructors with
`print_created(this)`/`print_destroyed(this)`/etc. functions which
provide similar output, but now has a unified format across the
different examples, including a new ### prefix that makes mixed example
output and lifecycle events easier to distinguish.
With this change, relaxed mode is no longer needed, which enables
testing for proper destruction under MSVC, and under any other compiler
that generates code calling extra constructors, or optimizes away any
constructors. GCC/clang are used as the baseline for move
constructors; the tests are adapted to allow more move constructors to
be evoked (but other types are constructors much have matching counts).
This commit also disables output buffering of tests, as the buffering
sometimes results in C++ output ending up in the middle of python
output (or vice versa), depending on the OS/python version.
2016-08-07 17:05:26 +00:00
|
|
|
~Movable() { print_destroyed(this); }
|
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
|
|
|
private:
|
|
|
|
int value;
|
|
|
|
};
|
|
|
|
|
|
|
|
class NCVirt {
|
|
|
|
public:
|
|
|
|
virtual NonCopyable get_noncopyable(int a, int b) { return NonCopyable(a, b); }
|
|
|
|
virtual Movable get_movable(int a, int b) = 0;
|
|
|
|
|
2016-08-19 11:45:36 +00:00
|
|
|
std::string print_nc(int a, int b) { return get_noncopyable(a, b).get_value(); }
|
|
|
|
std::string print_movable(int a, int b) { return get_movable(a, b).get_value(); }
|
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
|
|
|
};
|
|
|
|
class NCVirtTrampoline : public NCVirt {
|
2016-08-24 23:43:33 +00:00
|
|
|
#if !defined(__INTEL_COMPILER)
|
2016-09-08 18:47:05 +00:00
|
|
|
NonCopyable get_noncopyable(int a, int b) override {
|
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
|
|
|
PYBIND11_OVERLOAD(NonCopyable, NCVirt, get_noncopyable, a, b);
|
|
|
|
}
|
2016-08-24 23:43:33 +00:00
|
|
|
#endif
|
2016-09-08 18:47:05 +00:00
|
|
|
Movable get_movable(int a, int b) override {
|
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
|
|
|
PYBIND11_OVERLOAD_PURE(Movable, NCVirt, get_movable, a, b);
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
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
|
|
|
int runExampleVirt(ExampleVirt *ex, int value) {
|
2015-10-01 14:46:03 +00:00
|
|
|
return ex->run(value);
|
|
|
|
}
|
|
|
|
|
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
|
|
|
bool runExampleVirtBool(ExampleVirt* ex) {
|
2016-02-23 21:41:07 +00:00
|
|
|
return ex->run_bool();
|
|
|
|
}
|
|
|
|
|
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
|
|
|
void runExampleVirtVirtual(ExampleVirt *ex) {
|
2015-10-01 14:46:03 +00:00
|
|
|
ex->pure_virtual();
|
|
|
|
}
|
|
|
|
|
2016-08-05 21:02:33 +00:00
|
|
|
|
2016-08-05 21:44:28 +00:00
|
|
|
// Inheriting virtual methods. We do two versions here: the repeat-everything version and the
|
|
|
|
// templated trampoline versions mentioned in docs/advanced.rst.
|
2016-08-05 21:02:33 +00:00
|
|
|
//
|
2016-08-05 21:44:28 +00:00
|
|
|
// These base classes are exactly the same, but we technically need distinct
|
|
|
|
// classes for this example code because we need to be able to bind them
|
|
|
|
// properly (pybind11, sensibly, doesn't allow us to bind the same C++ class to
|
2016-08-05 21:02:33 +00:00
|
|
|
// multiple python classes).
|
|
|
|
class A_Repeat {
|
|
|
|
#define A_METHODS \
|
|
|
|
public: \
|
|
|
|
virtual int unlucky_number() = 0; \
|
2016-08-19 11:45:36 +00:00
|
|
|
virtual std::string say_something(unsigned times) { \
|
|
|
|
std::string s = ""; \
|
|
|
|
for (unsigned i = 0; i < times; ++i) \
|
|
|
|
s += "hi"; \
|
|
|
|
return s; \
|
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
|
|
|
} \
|
|
|
|
std::string say_everything() { \
|
|
|
|
return say_something(1) + " " + std::to_string(unlucky_number()); \
|
2016-08-05 21:02:33 +00:00
|
|
|
}
|
|
|
|
A_METHODS
|
|
|
|
};
|
|
|
|
class B_Repeat : public A_Repeat {
|
|
|
|
#define B_METHODS \
|
|
|
|
public: \
|
|
|
|
int unlucky_number() override { return 13; } \
|
2016-08-19 11:45:36 +00:00
|
|
|
std::string say_something(unsigned times) override { \
|
|
|
|
return "B says hi " + std::to_string(times) + " times"; \
|
2016-08-05 21:02:33 +00:00
|
|
|
} \
|
|
|
|
virtual double lucky_number() { return 7.0; }
|
|
|
|
B_METHODS
|
|
|
|
};
|
|
|
|
class C_Repeat : public B_Repeat {
|
|
|
|
#define C_METHODS \
|
|
|
|
public: \
|
|
|
|
int unlucky_number() override { return 4444; } \
|
|
|
|
double lucky_number() override { return 888; }
|
|
|
|
C_METHODS
|
|
|
|
};
|
|
|
|
class D_Repeat : public C_Repeat {
|
|
|
|
#define D_METHODS // Nothing overridden.
|
|
|
|
D_METHODS
|
|
|
|
};
|
|
|
|
|
|
|
|
// Base classes for templated inheritance trampolines. Identical to the repeat-everything version:
|
|
|
|
class A_Tpl { A_METHODS };
|
|
|
|
class B_Tpl : public A_Tpl { B_METHODS };
|
|
|
|
class C_Tpl : public B_Tpl { C_METHODS };
|
|
|
|
class D_Tpl : public C_Tpl { D_METHODS };
|
|
|
|
|
|
|
|
|
|
|
|
// Inheritance approach 1: each trampoline gets every virtual method (11 in total)
|
|
|
|
class PyA_Repeat : public A_Repeat {
|
|
|
|
public:
|
|
|
|
using A_Repeat::A_Repeat;
|
|
|
|
int unlucky_number() override { PYBIND11_OVERLOAD_PURE(int, A_Repeat, unlucky_number, ); }
|
2016-08-19 11:45:36 +00:00
|
|
|
std::string say_something(unsigned times) override { PYBIND11_OVERLOAD(std::string, A_Repeat, say_something, times); }
|
2016-08-05 21:02:33 +00:00
|
|
|
};
|
|
|
|
class PyB_Repeat : public B_Repeat {
|
|
|
|
public:
|
|
|
|
using B_Repeat::B_Repeat;
|
|
|
|
int unlucky_number() override { PYBIND11_OVERLOAD(int, B_Repeat, unlucky_number, ); }
|
2016-08-19 11:45:36 +00:00
|
|
|
std::string say_something(unsigned times) override { PYBIND11_OVERLOAD(std::string, B_Repeat, say_something, times); }
|
2016-08-05 21:02:33 +00:00
|
|
|
double lucky_number() override { PYBIND11_OVERLOAD(double, B_Repeat, lucky_number, ); }
|
|
|
|
};
|
|
|
|
class PyC_Repeat : public C_Repeat {
|
|
|
|
public:
|
|
|
|
using C_Repeat::C_Repeat;
|
|
|
|
int unlucky_number() override { PYBIND11_OVERLOAD(int, C_Repeat, unlucky_number, ); }
|
2016-08-19 11:45:36 +00:00
|
|
|
std::string say_something(unsigned times) override { PYBIND11_OVERLOAD(std::string, C_Repeat, say_something, times); }
|
2016-08-05 21:02:33 +00:00
|
|
|
double lucky_number() override { PYBIND11_OVERLOAD(double, C_Repeat, lucky_number, ); }
|
|
|
|
};
|
|
|
|
class PyD_Repeat : public D_Repeat {
|
|
|
|
public:
|
|
|
|
using D_Repeat::D_Repeat;
|
|
|
|
int unlucky_number() override { PYBIND11_OVERLOAD(int, D_Repeat, unlucky_number, ); }
|
2016-08-19 11:45:36 +00:00
|
|
|
std::string say_something(unsigned times) override { PYBIND11_OVERLOAD(std::string, D_Repeat, say_something, times); }
|
2016-08-05 21:02:33 +00:00
|
|
|
double lucky_number() override { PYBIND11_OVERLOAD(double, D_Repeat, lucky_number, ); }
|
|
|
|
};
|
|
|
|
|
|
|
|
// Inheritance approach 2: templated trampoline classes.
|
|
|
|
//
|
|
|
|
// Advantages:
|
|
|
|
// - we have only 2 (template) class and 4 method declarations (one per virtual method, plus one for
|
|
|
|
// any override of a pure virtual method), versus 4 classes and 6 methods (MI) or 4 classes and 11
|
|
|
|
// methods (repeat).
|
|
|
|
// - Compared to MI, we also don't have to change the non-trampoline inheritance to virtual, and can
|
|
|
|
// properly inherit constructors.
|
|
|
|
//
|
|
|
|
// Disadvantage:
|
|
|
|
// - the compiler must still generate and compile 14 different methods (more, even, than the 11
|
|
|
|
// required for the repeat approach) instead of the 6 required for MI. (If there was no pure
|
|
|
|
// method (or no pure method override), the number would drop down to the same 11 as the repeat
|
|
|
|
// approach).
|
|
|
|
template <class Base = A_Tpl>
|
|
|
|
class PyA_Tpl : public Base {
|
|
|
|
public:
|
|
|
|
using Base::Base; // Inherit constructors
|
|
|
|
int unlucky_number() override { PYBIND11_OVERLOAD_PURE(int, Base, unlucky_number, ); }
|
2016-08-19 11:45:36 +00:00
|
|
|
std::string say_something(unsigned times) override { PYBIND11_OVERLOAD(std::string, Base, say_something, times); }
|
2016-08-05 21:02:33 +00:00
|
|
|
};
|
|
|
|
template <class Base = B_Tpl>
|
|
|
|
class PyB_Tpl : public PyA_Tpl<Base> {
|
|
|
|
public:
|
|
|
|
using PyA_Tpl<Base>::PyA_Tpl; // Inherit constructors (via PyA_Tpl's inherited constructors)
|
|
|
|
int unlucky_number() override { PYBIND11_OVERLOAD(int, Base, unlucky_number, ); }
|
2016-08-11 22:59:57 +00:00
|
|
|
double lucky_number() override { PYBIND11_OVERLOAD(double, Base, lucky_number, ); }
|
2016-08-05 21:02:33 +00:00
|
|
|
};
|
|
|
|
// Since C_Tpl and D_Tpl don't declare any new virtual methods, we don't actually need these (we can
|
|
|
|
// use PyB_Tpl<C_Tpl> and PyB_Tpl<D_Tpl> for the trampoline classes instead):
|
|
|
|
/*
|
|
|
|
template <class Base = C_Tpl> class PyC_Tpl : public PyB_Tpl<Base> {
|
|
|
|
public:
|
|
|
|
using PyB_Tpl<Base>::PyB_Tpl;
|
|
|
|
};
|
|
|
|
template <class Base = D_Tpl> class PyD_Tpl : public PyC_Tpl<Base> {
|
|
|
|
public:
|
|
|
|
using PyC_Tpl<Base>::PyC_Tpl;
|
|
|
|
};
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
|
|
void initialize_inherited_virtuals(py::module &m) {
|
|
|
|
// Method 1: repeat
|
Allow arbitrary class_ template option ordering
The current pybind11::class_<Type, Holder, Trampoline> fixed template
ordering results in a requirement to repeat the Holder with its default
value (std::unique_ptr<Type>) argument, which is a little bit annoying:
it needs to be specified not because we want to override the default,
but rather because we need to specify the third argument.
This commit removes this limitation by making the class_ template take
the type name plus a parameter pack of options. It then extracts the
first valid holder type and the first subclass type for holder_type and
trampoline type_alias, respectively. (If unfound, both fall back to
their current defaults, `std::unique_ptr<type>` and `type`,
respectively). If any unmatched template arguments are provided, a
static assertion fails.
What this means is that you can specify or omit the arguments in any
order:
py::class_<A, PyA> c1(m, "A");
py::class_<B, PyB, std::shared_ptr<B>> c2(m, "B");
py::class_<C, std::shared_ptr<C>, PyB> c3(m, "C");
It also allows future class attributes (such as base types in the next
commit) to be passed as class template types rather than needing to use
a py::base<> wrapper.
2016-09-06 16:17:06 +00:00
|
|
|
py::class_<A_Repeat, PyA_Repeat>(m, "A_Repeat")
|
2016-08-05 21:02:33 +00:00
|
|
|
.def(py::init<>())
|
|
|
|
.def("unlucky_number", &A_Repeat::unlucky_number)
|
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", &A_Repeat::say_something)
|
|
|
|
.def("say_everything", &A_Repeat::say_everything);
|
2016-09-06 16:27:00 +00:00
|
|
|
py::class_<B_Repeat, A_Repeat, PyB_Repeat>(m, "B_Repeat")
|
2016-08-05 21:02:33 +00:00
|
|
|
.def(py::init<>())
|
|
|
|
.def("lucky_number", &B_Repeat::lucky_number);
|
2016-09-06 16:27:00 +00:00
|
|
|
py::class_<C_Repeat, B_Repeat, PyC_Repeat>(m, "C_Repeat")
|
2016-08-05 21:02:33 +00:00
|
|
|
.def(py::init<>());
|
2016-09-06 16:27:00 +00:00
|
|
|
py::class_<D_Repeat, C_Repeat, PyD_Repeat>(m, "D_Repeat")
|
2016-08-05 21:02:33 +00:00
|
|
|
.def(py::init<>());
|
|
|
|
|
|
|
|
// Method 2: Templated trampolines
|
Allow arbitrary class_ template option ordering
The current pybind11::class_<Type, Holder, Trampoline> fixed template
ordering results in a requirement to repeat the Holder with its default
value (std::unique_ptr<Type>) argument, which is a little bit annoying:
it needs to be specified not because we want to override the default,
but rather because we need to specify the third argument.
This commit removes this limitation by making the class_ template take
the type name plus a parameter pack of options. It then extracts the
first valid holder type and the first subclass type for holder_type and
trampoline type_alias, respectively. (If unfound, both fall back to
their current defaults, `std::unique_ptr<type>` and `type`,
respectively). If any unmatched template arguments are provided, a
static assertion fails.
What this means is that you can specify or omit the arguments in any
order:
py::class_<A, PyA> c1(m, "A");
py::class_<B, PyB, std::shared_ptr<B>> c2(m, "B");
py::class_<C, std::shared_ptr<C>, PyB> c3(m, "C");
It also allows future class attributes (such as base types in the next
commit) to be passed as class template types rather than needing to use
a py::base<> wrapper.
2016-09-06 16:17:06 +00:00
|
|
|
py::class_<A_Tpl, PyA_Tpl<>>(m, "A_Tpl")
|
2016-08-05 21:02:33 +00:00
|
|
|
.def(py::init<>())
|
|
|
|
.def("unlucky_number", &A_Tpl::unlucky_number)
|
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", &A_Tpl::say_something)
|
|
|
|
.def("say_everything", &A_Tpl::say_everything);
|
2016-09-06 16:27:00 +00:00
|
|
|
py::class_<B_Tpl, A_Tpl, PyB_Tpl<>>(m, "B_Tpl")
|
2016-08-05 21:02:33 +00:00
|
|
|
.def(py::init<>())
|
|
|
|
.def("lucky_number", &B_Tpl::lucky_number);
|
2016-09-06 16:27:00 +00:00
|
|
|
py::class_<C_Tpl, B_Tpl, PyB_Tpl<C_Tpl>>(m, "C_Tpl")
|
2016-08-05 21:02:33 +00:00
|
|
|
.def(py::init<>());
|
2016-09-06 16:27:00 +00:00
|
|
|
py::class_<D_Tpl, C_Tpl, PyB_Tpl<D_Tpl>>(m, "D_Tpl")
|
2016-08-05 21:02:33 +00:00
|
|
|
.def(py::init<>());
|
|
|
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
2016-09-03 18:54:22 +00:00
|
|
|
test_initializer virtual_functions([](py::module &m) {
|
Allow arbitrary class_ template option ordering
The current pybind11::class_<Type, Holder, Trampoline> fixed template
ordering results in a requirement to repeat the Holder with its default
value (std::unique_ptr<Type>) argument, which is a little bit annoying:
it needs to be specified not because we want to override the default,
but rather because we need to specify the third argument.
This commit removes this limitation by making the class_ template take
the type name plus a parameter pack of options. It then extracts the
first valid holder type and the first subclass type for holder_type and
trampoline type_alias, respectively. (If unfound, both fall back to
their current defaults, `std::unique_ptr<type>` and `type`,
respectively). If any unmatched template arguments are provided, a
static assertion fails.
What this means is that you can specify or omit the arguments in any
order:
py::class_<A, PyA> c1(m, "A");
py::class_<B, PyB, std::shared_ptr<B>> c2(m, "B");
py::class_<C, std::shared_ptr<C>, PyB> c3(m, "C");
It also allows future class attributes (such as base types in the next
commit) to be passed as class template types rather than needing to use
a py::base<> wrapper.
2016-09-06 16:17:06 +00:00
|
|
|
py::class_<ExampleVirt, PyExampleVirt>(m, "ExampleVirt")
|
2015-10-01 14:46:03 +00:00
|
|
|
.def(py::init<int>())
|
|
|
|
/* Reference original class in function definitions */
|
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
|
|
|
.def("run", &ExampleVirt::run)
|
|
|
|
.def("run_bool", &ExampleVirt::run_bool)
|
|
|
|
.def("pure_virtual", &ExampleVirt::pure_virtual);
|
2015-10-01 14:46:03 +00:00
|
|
|
|
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
|
|
|
py::class_<NonCopyable>(m, "NonCopyable")
|
2016-08-24 23:43:33 +00:00
|
|
|
.def(py::init<int, int>());
|
|
|
|
|
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
|
|
|
py::class_<Movable>(m, "Movable")
|
2016-08-24 23:43:33 +00:00
|
|
|
.def(py::init<int, int>());
|
|
|
|
|
|
|
|
#if !defined(__INTEL_COMPILER)
|
Allow arbitrary class_ template option ordering
The current pybind11::class_<Type, Holder, Trampoline> fixed template
ordering results in a requirement to repeat the Holder with its default
value (std::unique_ptr<Type>) argument, which is a little bit annoying:
it needs to be specified not because we want to override the default,
but rather because we need to specify the third argument.
This commit removes this limitation by making the class_ template take
the type name plus a parameter pack of options. It then extracts the
first valid holder type and the first subclass type for holder_type and
trampoline type_alias, respectively. (If unfound, both fall back to
their current defaults, `std::unique_ptr<type>` and `type`,
respectively). If any unmatched template arguments are provided, a
static assertion fails.
What this means is that you can specify or omit the arguments in any
order:
py::class_<A, PyA> c1(m, "A");
py::class_<B, PyB, std::shared_ptr<B>> c2(m, "B");
py::class_<C, std::shared_ptr<C>, PyB> c3(m, "C");
It also allows future class attributes (such as base types in the next
commit) to be passed as class template types rather than needing to use
a py::base<> wrapper.
2016-09-06 16:17:06 +00:00
|
|
|
py::class_<NCVirt, NCVirtTrampoline>(m, "NCVirt")
|
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
|
|
|
.def(py::init<>())
|
|
|
|
.def("get_noncopyable", &NCVirt::get_noncopyable)
|
|
|
|
.def("get_movable", &NCVirt::get_movable)
|
|
|
|
.def("print_nc", &NCVirt::print_nc)
|
2016-08-24 23:43:33 +00:00
|
|
|
.def("print_movable", &NCVirt::print_movable);
|
|
|
|
#endif
|
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
|
|
|
|
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
|
|
|
m.def("runExampleVirt", &runExampleVirt);
|
|
|
|
m.def("runExampleVirtBool", &runExampleVirtBool);
|
|
|
|
m.def("runExampleVirtVirtual", &runExampleVirtVirtual);
|
2016-08-05 21:02:33 +00:00
|
|
|
|
Improve constructor/destructor tracking
This commit rewrites the examples that look for constructor/destructor
calls to do so via static variable tracking rather than output parsing.
The added ConstructorStats class provides methods to keep track of
constructors and destructors, number of default/copy/move constructors,
and number of copy/move assignments. It also provides a mechanism for
storing values (e.g. for value construction), and then allows all of
this to be checked at the end of a test by getting the statistics for a
C++ (or python mapping) class.
By not relying on the precise pattern of constructions/destructions,
but rather simply ensuring that every construction is matched with a
destruction on the same object, we ensure that everything that gets
created also gets destroyed as expected.
This replaces all of the various "std::cout << whatever" code in
constructors/destructors with
`print_created(this)`/`print_destroyed(this)`/etc. functions which
provide similar output, but now has a unified format across the
different examples, including a new ### prefix that makes mixed example
output and lifecycle events easier to distinguish.
With this change, relaxed mode is no longer needed, which enables
testing for proper destruction under MSVC, and under any other compiler
that generates code calling extra constructors, or optimizes away any
constructors. GCC/clang are used as the baseline for move
constructors; the tests are adapted to allow more move constructors to
be evoked (but other types are constructors much have matching counts).
This commit also disables output buffering of tests, as the buffering
sometimes results in C++ output ending up in the middle of python
output (or vice versa), depending on the OS/python version.
2016-08-07 17:05:26 +00:00
|
|
|
m.def("cstats_debug", &ConstructorStats::get<ExampleVirt>);
|
2016-08-05 21:02:33 +00:00
|
|
|
initialize_inherited_virtuals(m);
|
2016-09-03 18:54:22 +00:00
|
|
|
});
|