Zengtudor/pybind11
1
0
Fork 0
mirror of https://github.com/pybind/pybind11.git synced 2025-02-22 16:39:29 +00:00
Code Issues Packages Projects Releases Wiki Activity
e2eca4f8f8
pybind11/include/pybind11/cast.h

2128 lines
87 KiB
C
Raw Normal View History

Initial commit
2015-07-05 18:05:44 +00:00
/*
last breaking change: be consistent about the project name
2015-10-15 16:13:33 +00:00
pybind11/cast.h: Partial template specializations to cast between
Initial commit
2015-07-05 18:05:44 +00:00
C++ and Python types
minor cleanups in common.h; updated author info and copyright year
2016-04-17 18:21:41 +00:00
Copyright (c) 2016 Wenzel Jakob <wenzel.jakob@epfl.ch>
Initial commit
2015-07-05 18:05:44 +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.
*/
more flexible function creation syntax
2015-07-11 15:41:48 +00:00
#pragma once
Initial commit
2015-07-05 18:05:44 +00:00
last breaking change: be consistent about the project name
2015-10-15 16:13:33 +00:00
#include "pytypes.h"
Move internal headers into `detail` subdirectory
2017-08-13 22:35:53 +00:00
#include "detail/typeid.h"
#include "detail/descr.h"
Move everything related to `internals` into a separate detail header
2017-08-20 14:15:33 +00:00
#include "detail/internals.h"
Initial commit
2015-07-05 18:05:44 +00:00
#include <array>
various minor compilation fixes
2015-08-28 15:53:31 +00:00
#include <limits>
vectorize: pass-through of non-vectorizable args This extends py::vectorize to automatically pass through non-vectorizable arguments. This removes the need for the documented "explicitly exclude an argument" workaround. Vectorization now applies to arithmetic, std::complex, and POD types, passed as plain value or by const lvalue reference (previously only pass-by-value types were supported). Non-const lvalue references and any other types are passed through as-is. Functions with rvalue reference arguments (whether vectorizable or not) are explicitly prohibited: an rvalue reference is inherently not something that can be passed multiple times and is thus unsuitable to being in a vectorized function. The vectorize returned value is also now more sensitive to inputs: previously it would return by value when all inputs are of size 1; this is now amended to having all inputs of size 1 *and* 0 dimensions. Thus if you pass in, for example, [[1]], you get back a 1x1, 2D array, while previously you got back just the resulting single value. Vectorization of member function specializations is now also supported via `py::vectorize(&Class::method)`; this required passthrough support for the initial object pointer on the wrapping function pointer.
2017-03-26 03:51:40 +00:00
#include <tuple>
Untangle cast logic to not implicitly require castability (#1442) The current code requires implicitly that integral types are cast-able to floating point. In case of strongly-typed integrals (e.g. as explained at http://www.ilikebigbits.com/blog/2014/5/6/type-safe-identifiers-in-c) this is not always the case. This commit uses SFINAE to move the numeric conversions into separate `cast()` implementations to avoid the issue.
2018-07-17 13:48:51 +00:00
#include <type_traits>
Initial commit
2015-07-05 18:05:44 +00:00
Support std::string_view when compiled under C++17
2017-06-19 00:32:22 +00:00
#if defined(PYBIND11_CPP17)
# if defined(__has_include)
# if __has_include(<string_view>)
# define PYBIND11_HAS_STRING_VIEW
# endif
# elif defined(_MSC_VER)
# define PYBIND11_HAS_STRING_VIEW
# endif
#endif
#ifdef PYBIND11_HAS_STRING_VIEW
#include <string_view>
#endif
Force hidden visibility on pybind code This adds a PYBIND11_NAMESPACE macro that expands to the `pybind11` namespace with hidden visibility under gcc-type compilers, and otherwise to the plain `pybind11`. This then forces hidden visibility on everything in pybind, solving the visibility issues discussed at end end of #949.
2017-08-10 16:03:29 +00:00
NAMESPACE_BEGIN(PYBIND11_NAMESPACE)
Initial commit
2015-07-05 18:05:44 +00:00
NAMESPACE_BEGIN(detail)
Add py::module_local() attribute for module-local type bindings This commit adds a `py::module_local` attribute that lets you confine a registered type to the module (more technically, the shared object) in which it is defined, by registering it with: py::class_<C>(m, "C", py::module_local()) This will allow the same C++ class `C` to be registered in different modules with independent sets of class definitions. On the Python side, two such types will be completely distinct; on the C++ side, the C++ type resolves to a different Python type in each module. This applies `py::module_local` automatically to `stl_bind.h` bindings when the container value type looks like something global: i.e. when it is a converting type (for example, when binding a `std::vector<int>`), or when it is a registered type itself bound with `py::module_local`. This should help resolve potential future conflicts (e.g. if two completely unrelated modules both try to bind a `std::vector<int>`. Users can override the automatic selection by adding a `py::module_local()` or `py::module_local(false)`. Note that this does mildly break backwards compatibility: bound stl containers of basic types like `std::vector<int>` cannot be bound in one module and returned in a different module. (This can be re-enabled with `py::module_local(false)` as described above, but with the potential for eventual load conflicts).
2017-07-29 02:03:44 +00:00
Add a life support system for type_caster temporaries
2017-06-26 18:34:06 +00:00
/// A life support system for temporary objects created by `type_caster::load()`.
/// Adding a patient will keep it alive up until the enclosing function returns.
class loader_life_support {
public:
/// A new patient frame is created when a function is entered
loader_life_support() {
get_internals().loader_patient_stack.push_back(nullptr);
}
/// ... and destroyed after it returns
~loader_life_support() {
auto &stack = get_internals().loader_patient_stack;
if (stack.empty())
pybind11_fail("loader_life_support: internal error");
auto ptr = stack.back();
stack.pop_back();
Py_CLEAR(ptr);
// A heuristic to reduce the stack's capacity (e.g. after long recursive calls)
if (stack.capacity() > 16 && stack.size() != 0 && stack.capacity() / stack.size() > 2)
stack.shrink_to_fit();
}
/// This can only be used inside a pybind11-bound function, either by `argument_loader`
/// at argument preparation time or by `py::cast()` at execution time.
PYBIND11_NOINLINE static void add_patient(handle h) {
auto &stack = get_internals().loader_patient_stack;
if (stack.empty())
throw cast_error("When called outside a bound function, py::cast() cannot "
"do Python -> C++ conversions which require the creation "
"of temporary values");
auto &list_ptr = stack.back();
if (list_ptr == nullptr) {
list_ptr = PyList_New(1);
if (!list_ptr)
pybind11_fail("loader_life_support: error allocating list");
PyList_SET_ITEM(list_ptr, 0, h.inc_ref().ptr());
} else {
auto result = PyList_Append(list_ptr, h.ptr());
if (result == -1)
pybind11_fail("loader_life_support: error adding patient");
}
}
};
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
// Gets the cache entry for the given type, creating it if necessary. The return value is the pair
// returned by emplace, i.e. an iterator for the entry and a bool set to `true` if the entry was
// just created.
inline std::pair<decltype(internals::registered_types_py)::iterator, bool> all_type_info_get_cache(PyTypeObject *type);
// Populates a just-created cache entry.
PYBIND11_NOINLINE inline void all_type_info_populate(PyTypeObject *t, std::vector<type_info *> &bases) {
std::vector<PyTypeObject *> check;
for (handle parent : reinterpret_borrow<tuple>(t->tp_bases))
check.push_back((PyTypeObject *) parent.ptr());
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
auto const &type_dict = get_internals().registered_types_py;
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
for (size_t i = 0; i < check.size(); i++) {
auto type = check[i];
// Ignore Python2 old-style class super type:
if (!PyType_Check((PyObject *) type)) continue;
// Check `type` in the current set of registered python types:
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
auto it = type_dict.find(type);
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
if (it != type_dict.end()) {
// We found a cache entry for it, so it's either pybind-registered or has pre-computed
// pybind bases, but we have to make sure we haven't already seen the type(s) before: we
// want to follow Python/virtual C++ rules that there should only be one instance of a
// common base.
for (auto *tinfo : it->second) {
// NB: Could use a second set here, rather than doing a linear search, but since
// having a large number of immediate pybind11-registered types seems fairly
// unlikely, that probably isn't worthwhile.
bool found = false;
for (auto *known : bases) {
if (known == tinfo) { found = true; break; }
}
if (!found) bases.push_back(tinfo);
}
}
else if (type->tp_bases) {
// It's some python type, so keep follow its bases classes to look for one or more
// registered types
if (i + 1 == check.size()) {
// When we're at the end, we can pop off the current element to avoid growing
Add py::module_local() attribute for module-local type bindings This commit adds a `py::module_local` attribute that lets you confine a registered type to the module (more technically, the shared object) in which it is defined, by registering it with: py::class_<C>(m, "C", py::module_local()) This will allow the same C++ class `C` to be registered in different modules with independent sets of class definitions. On the Python side, two such types will be completely distinct; on the C++ side, the C++ type resolves to a different Python type in each module. This applies `py::module_local` automatically to `stl_bind.h` bindings when the container value type looks like something global: i.e. when it is a converting type (for example, when binding a `std::vector<int>`), or when it is a registered type itself bound with `py::module_local`. This should help resolve potential future conflicts (e.g. if two completely unrelated modules both try to bind a `std::vector<int>`. Users can override the automatic selection by adding a `py::module_local()` or `py::module_local(false)`. Note that this does mildly break backwards compatibility: bound stl containers of basic types like `std::vector<int>` cannot be bound in one module and returned in a different module. (This can be re-enabled with `py::module_local(false)` as described above, but with the potential for eventual load conflicts).
2017-07-29 02:03:44 +00:00
// `check` when adding just one base (which is typical--i.e. when there is no
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
// multiple inheritance)
check.pop_back();
i--;
}
for (handle parent : reinterpret_borrow<tuple>(type->tp_bases))
check.push_back((PyTypeObject *) parent.ptr());
}
}
}
/**
* Extracts vector of type_info pointers of pybind-registered roots of the given Python type. Will
* be just 1 pybind type for the Python type of a pybind-registered class, or for any Python-side
* derived class that uses single inheritance. Will contain as many types as required for a Python
* class that uses multiple inheritance to inherit (directly or indirectly) from multiple
* pybind-registered classes. Will be empty if neither the type nor any base classes are
* pybind-registered.
*
* The value is cached for the lifetime of the Python type.
*/
inline const std::vector<detail::type_info *> &all_type_info(PyTypeObject *type) {
auto ins = all_type_info_get_cache(type);
if (ins.second)
// New cache entry: populate it
all_type_info_populate(type, ins.first->second);
return ins.first->second;
}
/**
* Gets a single pybind11 type info for a python type. Returns nullptr if neither the type nor any
* ancestors are pybind11-registered. Throws an exception if there are multiple bases--use
* `all_type_info` instead if you want to support multiple bases.
*/
PYBIND11_NOINLINE inline detail::type_info* get_type_info(PyTypeObject *type) {
auto &bases = all_type_info(type);
if (bases.size() == 0)
return nullptr;
if (bases.size() > 1)
pybind11_fail("pybind11::detail::get_type_info: type has multiple pybind11-registered bases");
return bases.front();
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
}
Allow module-local classes to be loaded externally The main point of `py::module_local` is to make the C++ -> Python cast unique so that returning/casting a C++ instance is well-defined. Unfortunately it also makes loading unique, but this isn't particularly desirable: when an instance contains `Type` instance there's no reason it shouldn't be possible to pass that instance to a bound function taking a `Type` parameter, even if that function is in another module. This commit solves the issue by allowing foreign module (and global) type loaders have a chance to load the value if the local module loader fails. The implementation here does this by storing a module-local loading function in a capsule in the python type, which we can then call if the local (and possibly global, if the local type is masking a global type) version doesn't work.
2017-08-17 15:38:05 +00:00
inline detail::type_info *get_local_type_info(const std::type_index &tp) {
Add py::module_local() attribute for module-local type bindings This commit adds a `py::module_local` attribute that lets you confine a registered type to the module (more technically, the shared object) in which it is defined, by registering it with: py::class_<C>(m, "C", py::module_local()) This will allow the same C++ class `C` to be registered in different modules with independent sets of class definitions. On the Python side, two such types will be completely distinct; on the C++ side, the C++ type resolves to a different Python type in each module. This applies `py::module_local` automatically to `stl_bind.h` bindings when the container value type looks like something global: i.e. when it is a converting type (for example, when binding a `std::vector<int>`), or when it is a registered type itself bound with `py::module_local`. This should help resolve potential future conflicts (e.g. if two completely unrelated modules both try to bind a `std::vector<int>`. Users can override the automatic selection by adding a `py::module_local()` or `py::module_local(false)`. Note that this does mildly break backwards compatibility: bound stl containers of basic types like `std::vector<int>` cannot be bound in one module and returned in a different module. (This can be re-enabled with `py::module_local(false)` as described above, but with the potential for eventual load conflicts).
2017-07-29 02:03:44 +00:00
auto &locals = registered_local_types_cpp();
Allow module-local classes to be loaded externally The main point of `py::module_local` is to make the C++ -> Python cast unique so that returning/casting a C++ instance is well-defined. Unfortunately it also makes loading unique, but this isn't particularly desirable: when an instance contains `Type` instance there's no reason it shouldn't be possible to pass that instance to a bound function taking a `Type` parameter, even if that function is in another module. This commit solves the issue by allowing foreign module (and global) type loaders have a chance to load the value if the local module loader fails. The implementation here does this by storing a module-local loading function in a capsule in the python type, which we can then call if the local (and possibly global, if the local type is masking a global type) version doesn't work.
2017-08-17 15:38:05 +00:00
auto it = locals.find(tp);
Add py::module_local() attribute for module-local type bindings This commit adds a `py::module_local` attribute that lets you confine a registered type to the module (more technically, the shared object) in which it is defined, by registering it with: py::class_<C>(m, "C", py::module_local()) This will allow the same C++ class `C` to be registered in different modules with independent sets of class definitions. On the Python side, two such types will be completely distinct; on the C++ side, the C++ type resolves to a different Python type in each module. This applies `py::module_local` automatically to `stl_bind.h` bindings when the container value type looks like something global: i.e. when it is a converting type (for example, when binding a `std::vector<int>`), or when it is a registered type itself bound with `py::module_local`. This should help resolve potential future conflicts (e.g. if two completely unrelated modules both try to bind a `std::vector<int>`. Users can override the automatic selection by adding a `py::module_local()` or `py::module_local(false)`. Note that this does mildly break backwards compatibility: bound stl containers of basic types like `std::vector<int>` cannot be bound in one module and returned in a different module. (This can be re-enabled with `py::module_local(false)` as described above, but with the potential for eventual load conflicts).
2017-07-29 02:03:44 +00:00
if (it != locals.end())
Improve type safety of internals.registered_types_cpp
2017-08-20 15:18:33 +00:00
return it->second;
Allow module-local classes to be loaded externally The main point of `py::module_local` is to make the C++ -> Python cast unique so that returning/casting a C++ instance is well-defined. Unfortunately it also makes loading unique, but this isn't particularly desirable: when an instance contains `Type` instance there's no reason it shouldn't be possible to pass that instance to a bound function taking a `Type` parameter, even if that function is in another module. This commit solves the issue by allowing foreign module (and global) type loaders have a chance to load the value if the local module loader fails. The implementation here does this by storing a module-local loading function in a capsule in the python type, which we can then call if the local (and possibly global, if the local type is masking a global type) version doesn't work.
2017-08-17 15:38:05 +00:00
return nullptr;
}
inline detail::type_info *get_global_type_info(const std::type_index &tp) {
auto &types = get_internals().registered_types_cpp;
auto it = types.find(tp);
if (it != types.end())
Improve type safety of internals.registered_types_cpp
2017-08-20 15:18:33 +00:00
return it->second;
Allow module-local classes to be loaded externally The main point of `py::module_local` is to make the C++ -> Python cast unique so that returning/casting a C++ instance is well-defined. Unfortunately it also makes loading unique, but this isn't particularly desirable: when an instance contains `Type` instance there's no reason it shouldn't be possible to pass that instance to a bound function taking a `Type` parameter, even if that function is in another module. This commit solves the issue by allowing foreign module (and global) type loaders have a chance to load the value if the local module loader fails. The implementation here does this by storing a module-local loading function in a capsule in the python type, which we can then call if the local (and possibly global, if the local type is masking a global type) version doesn't work.
2017-08-17 15:38:05 +00:00
return nullptr;
}
/// Return the type info for a given C++ type; on lookup failure can either throw or return nullptr.
PYBIND11_NOINLINE inline detail::type_info *get_type_info(const std::type_index &tp,
bool throw_if_missing = false) {
if (auto ltype = get_local_type_info(tp))
return ltype;
if (auto gtype = get_global_type_info(tp))
return gtype;
Multiple inheritance support
2016-09-11 11:00:40 +00:00
if (throw_if_missing) {
std::string tname = tp.name();
detail::clean_type_id(tname);
pybind11_fail("pybind11::detail::get_type_info: unable to find type info for \"" + tname + "\"");
}
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
return nullptr;
}
Multiple inheritance support
2016-09-11 11:00:40 +00:00
PYBIND11_NOINLINE inline handle get_type_handle(const std::type_info &tp, bool throw_if_missing) {
detail::type_info *type_info = get_type_info(tp, throw_if_missing);
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
return handle(type_info ? ((PyObject *) type_info->type) : nullptr);
}
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
struct value_and_holder {
instance *inst;
size_t index;
const detail::type_info *type;
void **vh;
Allow binding factory functions as constructors This allows you to use: cls.def(py::init(&factory_function)); where `factory_function` returns a pointer, holder, or value of the class type (or a derived type). Various compile-time checks (static_asserts) are performed to ensure the function is valid, and various run-time type checks where necessary. Some other details of this feature: - The `py::init` name doesn't conflict with the templated no-argument `py::init<...>()`, but keeps the naming consistent: the existing templated, no-argument one wraps constructors, the no-template, function-argument one wraps factory functions. - If returning a CppClass (whether by value or pointer) when an CppAlias is required (i.e. python-side inheritance and a declared alias), a dynamic_cast to the alias is attempted (for the pointer version); if it fails, or if returned by value, an Alias(Class &&) constructor is invoked. If this constructor doesn't exist, a runtime error occurs. - for holder returns when an alias is required, we try a dynamic_cast of the wrapped pointer to the alias to see if it is already an alias instance; if it isn't, we raise an error. - `py::init(class_factory, alias_factory)` is also available that takes two factories: the first is called when an alias is not needed, the second when it is. - Reimplement factory instance clearing. The previous implementation failed under python-side multiple inheritance: *each* inherited type's factory init would clear the instance instead of only setting its own type value. The new implementation here clears just the relevant value pointer. - dealloc is updated to explicitly set the leftover value pointer to nullptr and the `holder_constructed` flag to false so that it can be used to clear preallocated value without needing to rebuild the instance internals data. - Added various tests to test out new allocation/deallocation code. - With preallocation now done lazily, init factory holders can completely avoid the extra overhead of needing an extra allocation/deallocation. - Updated documentation to make factory constructors the default advanced constructor style. - If an `__init__` is called a second time, we have two choices: we can throw away the first instance, replacing it with the second; or we can ignore the second call. The latter is slightly easier, so do that.
2017-06-13 01:52:48 +00:00
// Main constructor for a found value/holder:
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
value_and_holder(instance *i, const detail::type_info *type, size_t vpos, size_t index) :
inst{i}, index{index}, type{type},
vh{inst->simple_layout ? inst->simple_value_holder : &inst->nonsimple.values_and_holders[vpos]}
{}
Allow binding factory functions as constructors This allows you to use: cls.def(py::init(&factory_function)); where `factory_function` returns a pointer, holder, or value of the class type (or a derived type). Various compile-time checks (static_asserts) are performed to ensure the function is valid, and various run-time type checks where necessary. Some other details of this feature: - The `py::init` name doesn't conflict with the templated no-argument `py::init<...>()`, but keeps the naming consistent: the existing templated, no-argument one wraps constructors, the no-template, function-argument one wraps factory functions. - If returning a CppClass (whether by value or pointer) when an CppAlias is required (i.e. python-side inheritance and a declared alias), a dynamic_cast to the alias is attempted (for the pointer version); if it fails, or if returned by value, an Alias(Class &&) constructor is invoked. If this constructor doesn't exist, a runtime error occurs. - for holder returns when an alias is required, we try a dynamic_cast of the wrapped pointer to the alias to see if it is already an alias instance; if it isn't, we raise an error. - `py::init(class_factory, alias_factory)` is also available that takes two factories: the first is called when an alias is not needed, the second when it is. - Reimplement factory instance clearing. The previous implementation failed under python-side multiple inheritance: *each* inherited type's factory init would clear the instance instead of only setting its own type value. The new implementation here clears just the relevant value pointer. - dealloc is updated to explicitly set the leftover value pointer to nullptr and the `holder_constructed` flag to false so that it can be used to clear preallocated value without needing to rebuild the instance internals data. - Added various tests to test out new allocation/deallocation code. - With preallocation now done lazily, init factory holders can completely avoid the extra overhead of needing an extra allocation/deallocation. - Updated documentation to make factory constructors the default advanced constructor style. - If an `__init__` is called a second time, we have two choices: we can throw away the first instance, replacing it with the second; or we can ignore the second call. The latter is slightly easier, so do that.
2017-06-13 01:52:48 +00:00
// Default constructor (used to signal a value-and-holder not found by get_value_and_holder())
value_and_holder() : inst{nullptr} {}
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
// Used for past-the-end iterator
value_and_holder(size_t index) : index{index} {}
template <typename V = void> V *&value_ptr() const {
return reinterpret_cast<V *&>(vh[0]);
}
// True if this `value_and_holder` has a non-null value pointer
explicit operator bool() const { return value_ptr(); }
template <typename H> H &holder() const {
return reinterpret_cast<H &>(vh[1]);
}
bool holder_constructed() const {
return inst->simple_layout
? inst->simple_holder_constructed
Fix occassional segfault introduced by #960 The fix for #960 could result a type being registered multiple times if its `__init__` is called multiple times. This can happen perfectly ordinarily when python-side multiple inheritance is involved: for example, with a diamond inheritance pattern with each intermediate classes invoking the parent constructor. With the change in #960, the multiple `__init__` calls meant `register_instance` was called multiple times, but the deletion only deleted it once. Thus, if a future instance of the same type was allocated at the same location, pybind would pick it up as a registered type. This fixes the issue by tracking whether a value pointer has been registered to avoid both double-registering it. (There's also a slight optimization of not needing to do a registered_instances lookup when the type is known not registered, but this is secondary).
2017-07-29 07:56:01 +00:00
: inst->nonsimple.status[index] & instance::status_holder_constructed;
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
}
Allow binding factory functions as constructors This allows you to use: cls.def(py::init(&factory_function)); where `factory_function` returns a pointer, holder, or value of the class type (or a derived type). Various compile-time checks (static_asserts) are performed to ensure the function is valid, and various run-time type checks where necessary. Some other details of this feature: - The `py::init` name doesn't conflict with the templated no-argument `py::init<...>()`, but keeps the naming consistent: the existing templated, no-argument one wraps constructors, the no-template, function-argument one wraps factory functions. - If returning a CppClass (whether by value or pointer) when an CppAlias is required (i.e. python-side inheritance and a declared alias), a dynamic_cast to the alias is attempted (for the pointer version); if it fails, or if returned by value, an Alias(Class &&) constructor is invoked. If this constructor doesn't exist, a runtime error occurs. - for holder returns when an alias is required, we try a dynamic_cast of the wrapped pointer to the alias to see if it is already an alias instance; if it isn't, we raise an error. - `py::init(class_factory, alias_factory)` is also available that takes two factories: the first is called when an alias is not needed, the second when it is. - Reimplement factory instance clearing. The previous implementation failed under python-side multiple inheritance: *each* inherited type's factory init would clear the instance instead of only setting its own type value. The new implementation here clears just the relevant value pointer. - dealloc is updated to explicitly set the leftover value pointer to nullptr and the `holder_constructed` flag to false so that it can be used to clear preallocated value without needing to rebuild the instance internals data. - Added various tests to test out new allocation/deallocation code. - With preallocation now done lazily, init factory holders can completely avoid the extra overhead of needing an extra allocation/deallocation. - Updated documentation to make factory constructors the default advanced constructor style. - If an `__init__` is called a second time, we have two choices: we can throw away the first instance, replacing it with the second; or we can ignore the second call. The latter is slightly easier, so do that.
2017-06-13 01:52:48 +00:00
void set_holder_constructed(bool v = true) {
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
if (inst->simple_layout)
Allow binding factory functions as constructors This allows you to use: cls.def(py::init(&factory_function)); where `factory_function` returns a pointer, holder, or value of the class type (or a derived type). Various compile-time checks (static_asserts) are performed to ensure the function is valid, and various run-time type checks where necessary. Some other details of this feature: - The `py::init` name doesn't conflict with the templated no-argument `py::init<...>()`, but keeps the naming consistent: the existing templated, no-argument one wraps constructors, the no-template, function-argument one wraps factory functions. - If returning a CppClass (whether by value or pointer) when an CppAlias is required (i.e. python-side inheritance and a declared alias), a dynamic_cast to the alias is attempted (for the pointer version); if it fails, or if returned by value, an Alias(Class &&) constructor is invoked. If this constructor doesn't exist, a runtime error occurs. - for holder returns when an alias is required, we try a dynamic_cast of the wrapped pointer to the alias to see if it is already an alias instance; if it isn't, we raise an error. - `py::init(class_factory, alias_factory)` is also available that takes two factories: the first is called when an alias is not needed, the second when it is. - Reimplement factory instance clearing. The previous implementation failed under python-side multiple inheritance: *each* inherited type's factory init would clear the instance instead of only setting its own type value. The new implementation here clears just the relevant value pointer. - dealloc is updated to explicitly set the leftover value pointer to nullptr and the `holder_constructed` flag to false so that it can be used to clear preallocated value without needing to rebuild the instance internals data. - Added various tests to test out new allocation/deallocation code. - With preallocation now done lazily, init factory holders can completely avoid the extra overhead of needing an extra allocation/deallocation. - Updated documentation to make factory constructors the default advanced constructor style. - If an `__init__` is called a second time, we have two choices: we can throw away the first instance, replacing it with the second; or we can ignore the second call. The latter is slightly easier, so do that.
2017-06-13 01:52:48 +00:00
inst->simple_holder_constructed = v;
else if (v)
Fix occassional segfault introduced by #960 The fix for #960 could result a type being registered multiple times if its `__init__` is called multiple times. This can happen perfectly ordinarily when python-side multiple inheritance is involved: for example, with a diamond inheritance pattern with each intermediate classes invoking the parent constructor. With the change in #960, the multiple `__init__` calls meant `register_instance` was called multiple times, but the deletion only deleted it once. Thus, if a future instance of the same type was allocated at the same location, pybind would pick it up as a registered type. This fixes the issue by tracking whether a value pointer has been registered to avoid both double-registering it. (There's also a slight optimization of not needing to do a registered_instances lookup when the type is known not registered, but this is secondary).
2017-07-29 07:56:01 +00:00
inst->nonsimple.status[index] |= instance::status_holder_constructed;
Allow binding factory functions as constructors This allows you to use: cls.def(py::init(&factory_function)); where `factory_function` returns a pointer, holder, or value of the class type (or a derived type). Various compile-time checks (static_asserts) are performed to ensure the function is valid, and various run-time type checks where necessary. Some other details of this feature: - The `py::init` name doesn't conflict with the templated no-argument `py::init<...>()`, but keeps the naming consistent: the existing templated, no-argument one wraps constructors, the no-template, function-argument one wraps factory functions. - If returning a CppClass (whether by value or pointer) when an CppAlias is required (i.e. python-side inheritance and a declared alias), a dynamic_cast to the alias is attempted (for the pointer version); if it fails, or if returned by value, an Alias(Class &&) constructor is invoked. If this constructor doesn't exist, a runtime error occurs. - for holder returns when an alias is required, we try a dynamic_cast of the wrapped pointer to the alias to see if it is already an alias instance; if it isn't, we raise an error. - `py::init(class_factory, alias_factory)` is also available that takes two factories: the first is called when an alias is not needed, the second when it is. - Reimplement factory instance clearing. The previous implementation failed under python-side multiple inheritance: *each* inherited type's factory init would clear the instance instead of only setting its own type value. The new implementation here clears just the relevant value pointer. - dealloc is updated to explicitly set the leftover value pointer to nullptr and the `holder_constructed` flag to false so that it can be used to clear preallocated value without needing to rebuild the instance internals data. - Added various tests to test out new allocation/deallocation code. - With preallocation now done lazily, init factory holders can completely avoid the extra overhead of needing an extra allocation/deallocation. - Updated documentation to make factory constructors the default advanced constructor style. - If an `__init__` is called a second time, we have two choices: we can throw away the first instance, replacing it with the second; or we can ignore the second call. The latter is slightly easier, so do that.
2017-06-13 01:52:48 +00:00
else
inst->nonsimple.status[index] &= (uint8_t) ~instance::status_holder_constructed;
Fix occassional segfault introduced by #960 The fix for #960 could result a type being registered multiple times if its `__init__` is called multiple times. This can happen perfectly ordinarily when python-side multiple inheritance is involved: for example, with a diamond inheritance pattern with each intermediate classes invoking the parent constructor. With the change in #960, the multiple `__init__` calls meant `register_instance` was called multiple times, but the deletion only deleted it once. Thus, if a future instance of the same type was allocated at the same location, pybind would pick it up as a registered type. This fixes the issue by tracking whether a value pointer has been registered to avoid both double-registering it. (There's also a slight optimization of not needing to do a registered_instances lookup when the type is known not registered, but this is secondary).
2017-07-29 07:56:01 +00:00
}
bool instance_registered() const {
return inst->simple_layout
? inst->simple_instance_registered
: inst->nonsimple.status[index] & instance::status_instance_registered;
}
Allow binding factory functions as constructors This allows you to use: cls.def(py::init(&factory_function)); where `factory_function` returns a pointer, holder, or value of the class type (or a derived type). Various compile-time checks (static_asserts) are performed to ensure the function is valid, and various run-time type checks where necessary. Some other details of this feature: - The `py::init` name doesn't conflict with the templated no-argument `py::init<...>()`, but keeps the naming consistent: the existing templated, no-argument one wraps constructors, the no-template, function-argument one wraps factory functions. - If returning a CppClass (whether by value or pointer) when an CppAlias is required (i.e. python-side inheritance and a declared alias), a dynamic_cast to the alias is attempted (for the pointer version); if it fails, or if returned by value, an Alias(Class &&) constructor is invoked. If this constructor doesn't exist, a runtime error occurs. - for holder returns when an alias is required, we try a dynamic_cast of the wrapped pointer to the alias to see if it is already an alias instance; if it isn't, we raise an error. - `py::init(class_factory, alias_factory)` is also available that takes two factories: the first is called when an alias is not needed, the second when it is. - Reimplement factory instance clearing. The previous implementation failed under python-side multiple inheritance: *each* inherited type's factory init would clear the instance instead of only setting its own type value. The new implementation here clears just the relevant value pointer. - dealloc is updated to explicitly set the leftover value pointer to nullptr and the `holder_constructed` flag to false so that it can be used to clear preallocated value without needing to rebuild the instance internals data. - Added various tests to test out new allocation/deallocation code. - With preallocation now done lazily, init factory holders can completely avoid the extra overhead of needing an extra allocation/deallocation. - Updated documentation to make factory constructors the default advanced constructor style. - If an `__init__` is called a second time, we have two choices: we can throw away the first instance, replacing it with the second; or we can ignore the second call. The latter is slightly easier, so do that.
2017-06-13 01:52:48 +00:00
void set_instance_registered(bool v = true) {
Fix occassional segfault introduced by #960 The fix for #960 could result a type being registered multiple times if its `__init__` is called multiple times. This can happen perfectly ordinarily when python-side multiple inheritance is involved: for example, with a diamond inheritance pattern with each intermediate classes invoking the parent constructor. With the change in #960, the multiple `__init__` calls meant `register_instance` was called multiple times, but the deletion only deleted it once. Thus, if a future instance of the same type was allocated at the same location, pybind would pick it up as a registered type. This fixes the issue by tracking whether a value pointer has been registered to avoid both double-registering it. (There's also a slight optimization of not needing to do a registered_instances lookup when the type is known not registered, but this is secondary).
2017-07-29 07:56:01 +00:00
if (inst->simple_layout)
Allow binding factory functions as constructors This allows you to use: cls.def(py::init(&factory_function)); where `factory_function` returns a pointer, holder, or value of the class type (or a derived type). Various compile-time checks (static_asserts) are performed to ensure the function is valid, and various run-time type checks where necessary. Some other details of this feature: - The `py::init` name doesn't conflict with the templated no-argument `py::init<...>()`, but keeps the naming consistent: the existing templated, no-argument one wraps constructors, the no-template, function-argument one wraps factory functions. - If returning a CppClass (whether by value or pointer) when an CppAlias is required (i.e. python-side inheritance and a declared alias), a dynamic_cast to the alias is attempted (for the pointer version); if it fails, or if returned by value, an Alias(Class &&) constructor is invoked. If this constructor doesn't exist, a runtime error occurs. - for holder returns when an alias is required, we try a dynamic_cast of the wrapped pointer to the alias to see if it is already an alias instance; if it isn't, we raise an error. - `py::init(class_factory, alias_factory)` is also available that takes two factories: the first is called when an alias is not needed, the second when it is. - Reimplement factory instance clearing. The previous implementation failed under python-side multiple inheritance: *each* inherited type's factory init would clear the instance instead of only setting its own type value. The new implementation here clears just the relevant value pointer. - dealloc is updated to explicitly set the leftover value pointer to nullptr and the `holder_constructed` flag to false so that it can be used to clear preallocated value without needing to rebuild the instance internals data. - Added various tests to test out new allocation/deallocation code. - With preallocation now done lazily, init factory holders can completely avoid the extra overhead of needing an extra allocation/deallocation. - Updated documentation to make factory constructors the default advanced constructor style. - If an `__init__` is called a second time, we have two choices: we can throw away the first instance, replacing it with the second; or we can ignore the second call. The latter is slightly easier, so do that.
2017-06-13 01:52:48 +00:00
inst->simple_instance_registered = v;
else if (v)
Fix occassional segfault introduced by #960 The fix for #960 could result a type being registered multiple times if its `__init__` is called multiple times. This can happen perfectly ordinarily when python-side multiple inheritance is involved: for example, with a diamond inheritance pattern with each intermediate classes invoking the parent constructor. With the change in #960, the multiple `__init__` calls meant `register_instance` was called multiple times, but the deletion only deleted it once. Thus, if a future instance of the same type was allocated at the same location, pybind would pick it up as a registered type. This fixes the issue by tracking whether a value pointer has been registered to avoid both double-registering it. (There's also a slight optimization of not needing to do a registered_instances lookup when the type is known not registered, but this is secondary).
2017-07-29 07:56:01 +00:00
inst->nonsimple.status[index] |= instance::status_instance_registered;
Allow binding factory functions as constructors This allows you to use: cls.def(py::init(&factory_function)); where `factory_function` returns a pointer, holder, or value of the class type (or a derived type). Various compile-time checks (static_asserts) are performed to ensure the function is valid, and various run-time type checks where necessary. Some other details of this feature: - The `py::init` name doesn't conflict with the templated no-argument `py::init<...>()`, but keeps the naming consistent: the existing templated, no-argument one wraps constructors, the no-template, function-argument one wraps factory functions. - If returning a CppClass (whether by value or pointer) when an CppAlias is required (i.e. python-side inheritance and a declared alias), a dynamic_cast to the alias is attempted (for the pointer version); if it fails, or if returned by value, an Alias(Class &&) constructor is invoked. If this constructor doesn't exist, a runtime error occurs. - for holder returns when an alias is required, we try a dynamic_cast of the wrapped pointer to the alias to see if it is already an alias instance; if it isn't, we raise an error. - `py::init(class_factory, alias_factory)` is also available that takes two factories: the first is called when an alias is not needed, the second when it is. - Reimplement factory instance clearing. The previous implementation failed under python-side multiple inheritance: *each* inherited type's factory init would clear the instance instead of only setting its own type value. The new implementation here clears just the relevant value pointer. - dealloc is updated to explicitly set the leftover value pointer to nullptr and the `holder_constructed` flag to false so that it can be used to clear preallocated value without needing to rebuild the instance internals data. - Added various tests to test out new allocation/deallocation code. - With preallocation now done lazily, init factory holders can completely avoid the extra overhead of needing an extra allocation/deallocation. - Updated documentation to make factory constructors the default advanced constructor style. - If an `__init__` is called a second time, we have two choices: we can throw away the first instance, replacing it with the second; or we can ignore the second call. The latter is slightly easier, so do that.
2017-06-13 01:52:48 +00:00
else
inst->nonsimple.status[index] &= (uint8_t) ~instance::status_instance_registered;
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
}
};
// Container for accessing and iterating over an instance's values/holders
struct values_and_holders {
private:
instance *inst;
using type_vec = std::vector<detail::type_info *>;
const type_vec &tinfo;
public:
values_and_holders(instance *inst) : inst{inst}, tinfo(all_type_info(Py_TYPE(inst))) {}
struct iterator {
private:
instance *inst;
Fix past-the-end dereference in values_and_holders The value and holder iterator code had a past-the-end iterator dereference. While of course invalid, the dereference didn't actually cause any problems (which is why it wasn't caught before) because the dereferenced value is never actually used and `vector` implementations appear to allow dereferencing the past-the-end iterator. Under a MSVC debug build, however, it fails a debug assertion and aborts. This amends the iterator to just store and use a pointer to the vector (rather than adding a second past-the-end iterator member), checking the type index against the type vector size.
2017-07-12 14:18:09 +00:00
const type_vec *types;
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
value_and_holder curr;
friend struct values_and_holders;
Fix past-the-end dereference in values_and_holders The value and holder iterator code had a past-the-end iterator dereference. While of course invalid, the dereference didn't actually cause any problems (which is why it wasn't caught before) because the dereferenced value is never actually used and `vector` implementations appear to allow dereferencing the past-the-end iterator. Under a MSVC debug build, however, it fails a debug assertion and aborts. This amends the iterator to just store and use a pointer to the vector (rather than adding a second past-the-end iterator member), checking the type index against the type vector size.
2017-07-12 14:18:09 +00:00
iterator(instance *inst, const type_vec *tinfo)
: inst{inst}, types{tinfo},
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
curr(inst /* instance */,
Fix past-the-end dereference in values_and_holders The value and holder iterator code had a past-the-end iterator dereference. While of course invalid, the dereference didn't actually cause any problems (which is why it wasn't caught before) because the dereferenced value is never actually used and `vector` implementations appear to allow dereferencing the past-the-end iterator. Under a MSVC debug build, however, it fails a debug assertion and aborts. This amends the iterator to just store and use a pointer to the vector (rather than adding a second past-the-end iterator member), checking the type index against the type vector size.
2017-07-12 14:18:09 +00:00
types->empty() ? nullptr : (*types)[0] /* type info */,
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
0, /* vpos: (non-simple types only): the first vptr comes first */
0 /* index */)
{}
// Past-the-end iterator:
iterator(size_t end) : curr(end) {}
public:
bool operator==(const iterator &other) { return curr.index == other.curr.index; }
bool operator!=(const iterator &other) { return curr.index != other.curr.index; }
iterator &operator++() {
Fix past-the-end dereference in values_and_holders The value and holder iterator code had a past-the-end iterator dereference. While of course invalid, the dereference didn't actually cause any problems (which is why it wasn't caught before) because the dereferenced value is never actually used and `vector` implementations appear to allow dereferencing the past-the-end iterator. Under a MSVC debug build, however, it fails a debug assertion and aborts. This amends the iterator to just store and use a pointer to the vector (rather than adding a second past-the-end iterator member), checking the type index against the type vector size.
2017-07-12 14:18:09 +00:00
if (!inst->simple_layout)
curr.vh += 1 + (*types)[curr.index]->holder_size_in_ptrs;
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
++curr.index;
Fix past-the-end dereference in values_and_holders The value and holder iterator code had a past-the-end iterator dereference. While of course invalid, the dereference didn't actually cause any problems (which is why it wasn't caught before) because the dereferenced value is never actually used and `vector` implementations appear to allow dereferencing the past-the-end iterator. Under a MSVC debug build, however, it fails a debug assertion and aborts. This amends the iterator to just store and use a pointer to the vector (rather than adding a second past-the-end iterator member), checking the type index against the type vector size.
2017-07-12 14:18:09 +00:00
curr.type = curr.index < types->size() ? (*types)[curr.index] : nullptr;
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
return *this;
}
value_and_holder &operator*() { return curr; }
value_and_holder *operator->() { return &curr; }
};
Fix past-the-end dereference in values_and_holders The value and holder iterator code had a past-the-end iterator dereference. While of course invalid, the dereference didn't actually cause any problems (which is why it wasn't caught before) because the dereferenced value is never actually used and `vector` implementations appear to allow dereferencing the past-the-end iterator. Under a MSVC debug build, however, it fails a debug assertion and aborts. This amends the iterator to just store and use a pointer to the vector (rather than adding a second past-the-end iterator member), checking the type index against the type vector size.
2017-07-12 14:18:09 +00:00
iterator begin() { return iterator(inst, &tinfo); }
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
iterator end() { return iterator(tinfo.size()); }
iterator find(const type_info *find_type) {
auto it = begin(), endit = end();
while (it != endit && it->type != find_type) ++it;
return it;
}
size_t size() { return tinfo.size(); }
};
/**
* Extracts C++ value and holder pointer references from an instance (which may contain multiple
* values/holders for python-side multiple inheritance) that match the given type. Throws an error
* if the given type (or ValueType, if omitted) is not a pybind11 base of the given instance. If
* `find_type` is omitted (or explicitly specified as nullptr) the first value/holder are returned,
* regardless of type (and the resulting .type will be nullptr).
*
* The returned object should be short-lived: in particular, it must not outlive the called-upon
* instance.
*/
Allow binding factory functions as constructors This allows you to use: cls.def(py::init(&factory_function)); where `factory_function` returns a pointer, holder, or value of the class type (or a derived type). Various compile-time checks (static_asserts) are performed to ensure the function is valid, and various run-time type checks where necessary. Some other details of this feature: - The `py::init` name doesn't conflict with the templated no-argument `py::init<...>()`, but keeps the naming consistent: the existing templated, no-argument one wraps constructors, the no-template, function-argument one wraps factory functions. - If returning a CppClass (whether by value or pointer) when an CppAlias is required (i.e. python-side inheritance and a declared alias), a dynamic_cast to the alias is attempted (for the pointer version); if it fails, or if returned by value, an Alias(Class &&) constructor is invoked. If this constructor doesn't exist, a runtime error occurs. - for holder returns when an alias is required, we try a dynamic_cast of the wrapped pointer to the alias to see if it is already an alias instance; if it isn't, we raise an error. - `py::init(class_factory, alias_factory)` is also available that takes two factories: the first is called when an alias is not needed, the second when it is. - Reimplement factory instance clearing. The previous implementation failed under python-side multiple inheritance: *each* inherited type's factory init would clear the instance instead of only setting its own type value. The new implementation here clears just the relevant value pointer. - dealloc is updated to explicitly set the leftover value pointer to nullptr and the `holder_constructed` flag to false so that it can be used to clear preallocated value without needing to rebuild the instance internals data. - Added various tests to test out new allocation/deallocation code. - With preallocation now done lazily, init factory holders can completely avoid the extra overhead of needing an extra allocation/deallocation. - Updated documentation to make factory constructors the default advanced constructor style. - If an `__init__` is called a second time, we have two choices: we can throw away the first instance, replacing it with the second; or we can ignore the second call. The latter is slightly easier, so do that.
2017-06-13 01:52:48 +00:00
PYBIND11_NOINLINE inline value_and_holder instance::get_value_and_holder(const type_info *find_type /*= nullptr default in common.h*/, bool throw_if_missing /*= true in common.h*/) {
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
// Optimize common case:
if (!find_type || Py_TYPE(this) == find_type->type)
return value_and_holder(this, find_type, 0, 0);
detail::values_and_holders vhs(this);
auto it = vhs.find(find_type);
if (it != vhs.end())
return *it;
Allow binding factory functions as constructors This allows you to use: cls.def(py::init(&factory_function)); where `factory_function` returns a pointer, holder, or value of the class type (or a derived type). Various compile-time checks (static_asserts) are performed to ensure the function is valid, and various run-time type checks where necessary. Some other details of this feature: - The `py::init` name doesn't conflict with the templated no-argument `py::init<...>()`, but keeps the naming consistent: the existing templated, no-argument one wraps constructors, the no-template, function-argument one wraps factory functions. - If returning a CppClass (whether by value or pointer) when an CppAlias is required (i.e. python-side inheritance and a declared alias), a dynamic_cast to the alias is attempted (for the pointer version); if it fails, or if returned by value, an Alias(Class &&) constructor is invoked. If this constructor doesn't exist, a runtime error occurs. - for holder returns when an alias is required, we try a dynamic_cast of the wrapped pointer to the alias to see if it is already an alias instance; if it isn't, we raise an error. - `py::init(class_factory, alias_factory)` is also available that takes two factories: the first is called when an alias is not needed, the second when it is. - Reimplement factory instance clearing. The previous implementation failed under python-side multiple inheritance: *each* inherited type's factory init would clear the instance instead of only setting its own type value. The new implementation here clears just the relevant value pointer. - dealloc is updated to explicitly set the leftover value pointer to nullptr and the `holder_constructed` flag to false so that it can be used to clear preallocated value without needing to rebuild the instance internals data. - Added various tests to test out new allocation/deallocation code. - With preallocation now done lazily, init factory holders can completely avoid the extra overhead of needing an extra allocation/deallocation. - Updated documentation to make factory constructors the default advanced constructor style. - If an `__init__` is called a second time, we have two choices: we can throw away the first instance, replacing it with the second; or we can ignore the second call. The latter is slightly easier, so do that.
2017-06-13 01:52:48 +00:00
if (!throw_if_missing)
return value_and_holder();
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
#if defined(NDEBUG)
pybind11_fail("pybind11::detail::instance::get_value_and_holder: "
"type is not a pybind11 base of the given instance "
"(compile in debug mode for type details)");
#else
pybind11_fail("pybind11::detail::instance::get_value_and_holder: `" +
std::string(find_type->type->tp_name) + "' is not a pybind11 base of the given `" +
std::string(Py_TYPE(this)->tp_name) + "' instance");
#endif
}
PYBIND11_NOINLINE inline void instance::allocate_layout() {
auto &tinfo = all_type_info(Py_TYPE(this));
const size_t n_types = tinfo.size();
if (n_types == 0)
pybind11_fail("instance allocation failed: new instance has no pybind11-registered base types");
simple_layout =
n_types == 1 && tinfo.front()->holder_size_in_ptrs <= instance_simple_holder_in_ptrs();
// Simple path: no python-side multiple inheritance, and a small-enough holder
if (simple_layout) {
simple_value_holder[0] = nullptr;
simple_holder_constructed = false;
Fix occassional segfault introduced by #960 The fix for #960 could result a type being registered multiple times if its `__init__` is called multiple times. This can happen perfectly ordinarily when python-side multiple inheritance is involved: for example, with a diamond inheritance pattern with each intermediate classes invoking the parent constructor. With the change in #960, the multiple `__init__` calls meant `register_instance` was called multiple times, but the deletion only deleted it once. Thus, if a future instance of the same type was allocated at the same location, pybind would pick it up as a registered type. This fixes the issue by tracking whether a value pointer has been registered to avoid both double-registering it. (There's also a slight optimization of not needing to do a registered_instances lookup when the type is known not registered, but this is secondary).
2017-07-29 07:56:01 +00:00
simple_instance_registered = false;
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
}
else { // multiple base types or a too-large holder
// Allocate space to hold: [v1*][h1][v2*][h2]...[bb...] where [vN*] is a value pointer,
// [hN] is the (uninitialized) holder instance for value N, and [bb...] is a set of bool
// values that tracks whether each associated holder has been initialized. Each [block] is
// padded, if necessary, to an integer multiple of sizeof(void *).
size_t space = 0;
for (auto t : tinfo) {
space += 1; // value pointer
space += t->holder_size_in_ptrs; // holder instance
}
size_t flags_at = space;
Fix occassional segfault introduced by #960 The fix for #960 could result a type being registered multiple times if its `__init__` is called multiple times. This can happen perfectly ordinarily when python-side multiple inheritance is involved: for example, with a diamond inheritance pattern with each intermediate classes invoking the parent constructor. With the change in #960, the multiple `__init__` calls meant `register_instance` was called multiple times, but the deletion only deleted it once. Thus, if a future instance of the same type was allocated at the same location, pybind would pick it up as a registered type. This fixes the issue by tracking whether a value pointer has been registered to avoid both double-registering it. (There's also a slight optimization of not needing to do a registered_instances lookup when the type is known not registered, but this is secondary).
2017-07-29 07:56:01 +00:00
space += size_in_ptrs(n_types); // status bytes (holder_constructed and instance_registered)
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
// Allocate space for flags, values, and holders, and initialize it to 0 (flags and values,
// in particular, need to be 0). Use Python's memory allocation functions: in Python 3.6
// they default to using pymalloc, which is designed to be efficient for small allocations
// like the one we're doing here; in earlier versions (and for larger allocations) they are
// just wrappers around malloc.
#if PY_VERSION_HEX >= 0x03050000
nonsimple.values_and_holders = (void **) PyMem_Calloc(space, sizeof(void *));
if (!nonsimple.values_and_holders) throw std::bad_alloc();
#else
nonsimple.values_and_holders = (void **) PyMem_New(void *, space);
if (!nonsimple.values_and_holders) throw std::bad_alloc();
std::memset(nonsimple.values_and_holders, 0, space * sizeof(void *));
#endif
Fix occassional segfault introduced by #960 The fix for #960 could result a type being registered multiple times if its `__init__` is called multiple times. This can happen perfectly ordinarily when python-side multiple inheritance is involved: for example, with a diamond inheritance pattern with each intermediate classes invoking the parent constructor. With the change in #960, the multiple `__init__` calls meant `register_instance` was called multiple times, but the deletion only deleted it once. Thus, if a future instance of the same type was allocated at the same location, pybind would pick it up as a registered type. This fixes the issue by tracking whether a value pointer has been registered to avoid both double-registering it. (There's also a slight optimization of not needing to do a registered_instances lookup when the type is known not registered, but this is secondary).
2017-07-29 07:56:01 +00:00
nonsimple.status = reinterpret_cast<uint8_t *>(&nonsimple.values_and_holders[flags_at]);
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
}
owned = true;
}
PYBIND11_NOINLINE inline void instance::deallocate_layout() {
if (!simple_layout)
PyMem_Free(nonsimple.values_and_holders);
}
Add py::isinstance<T>(obj) for generalized Python type checking Allows checking the Python types before creating an object instead of after. For example: ```c++ auto l = list(ptr, true); if (l.check()) // ... ``` The above is replaced with: ```c++ if (isinstance<list>(ptr)) { auto l = reinterpret_borrow(ptr); // ... } ``` This deprecates `py::object::check()`. `py::isinstance()` covers the same use case, but it can also check for user-defined types: ```c++ class Pet { ... }; py::class_<Pet>(...); m.def("is_pet", [](py::object obj) { return py::isinstance<Pet>(obj); // works as expected }); ```
2016-10-23 12:50:08 +00:00
PYBIND11_NOINLINE inline bool isinstance_generic(handle obj, const std::type_info &tp) {
WIP: PyPy support (#527) This commit includes modifications that are needed to get pybind11 to work with PyPy. The full test suite compiles and runs except for a last few functions that are commented out (due to problems in PyPy that were reported on the PyPy bugtracker). Two somewhat intrusive changes were needed to make it possible: two new tags ``py::buffer_protocol()`` and ``py::metaclass()`` must now be specified to the ``class_`` constructor if the class uses the buffer protocol and/or requires a metaclass (e.g. for static properties). Note that this is only for the PyPy version based on Python 2.7 for now. When the PyPy 3.x has caught up in terms of cpyext compliance, a PyPy 3.x patch will follow.
2016-12-16 14:00:46 +00:00
handle type = detail::get_type_handle(tp, false);
Add py::isinstance<T>(obj) for generalized Python type checking Allows checking the Python types before creating an object instead of after. For example: ```c++ auto l = list(ptr, true); if (l.check()) // ... ``` The above is replaced with: ```c++ if (isinstance<list>(ptr)) { auto l = reinterpret_borrow(ptr); // ... } ``` This deprecates `py::object::check()`. `py::isinstance()` covers the same use case, but it can also check for user-defined types: ```c++ class Pet { ... }; py::class_<Pet>(...); m.def("is_pet", [](py::object obj) { return py::isinstance<Pet>(obj); // works as expected }); ```
2016-10-23 12:50:08 +00:00
if (!type)
return false;
WIP: PyPy support (#527) This commit includes modifications that are needed to get pybind11 to work with PyPy. The full test suite compiles and runs except for a last few functions that are commented out (due to problems in PyPy that were reported on the PyPy bugtracker). Two somewhat intrusive changes were needed to make it possible: two new tags ``py::buffer_protocol()`` and ``py::metaclass()`` must now be specified to the ``class_`` constructor if the class uses the buffer protocol and/or requires a metaclass (e.g. for static properties). Note that this is only for the PyPy version based on Python 2.7 for now. When the PyPy 3.x has caught up in terms of cpyext compliance, a PyPy 3.x patch will follow.
2016-12-16 14:00:46 +00:00
return isinstance(obj, type);
Add py::isinstance<T>(obj) for generalized Python type checking Allows checking the Python types before creating an object instead of after. For example: ```c++ auto l = list(ptr, true); if (l.check()) // ... ``` The above is replaced with: ```c++ if (isinstance<list>(ptr)) { auto l = reinterpret_borrow(ptr); // ... } ``` This deprecates `py::object::check()`. `py::isinstance()` covers the same use case, but it can also check for user-defined types: ```c++ class Pet { ... }; py::class_<Pet>(...); m.def("is_pet", [](py::object obj) { return py::isinstance<Pet>(obj); // works as expected }); ```
2016-10-23 12:50:08 +00:00
}
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
PYBIND11_NOINLINE inline std::string error_string() {
Set error if it's not set in error_already_set()
2016-09-07 20:10:16 +00:00
if (!PyErr_Occurred()) {
PyErr_SetString(PyExc_RuntimeError, "Unknown internal error occurred");
return "Unknown internal error occurred";
}
RAII wrapper for error state
2016-09-10 07:32:17 +00:00
error_scope scope; // Preserve error state
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
Set error if it's not set in error_already_set()
2016-09-07 20:10:16 +00:00
std::string errorString;
RAII wrapper for error state
2016-09-10 07:32:17 +00:00
if (scope.type) {
errorString += handle(scope.type).attr("__name__").cast<std::string>();
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
errorString += ": ";
}
RAII wrapper for error state
2016-09-10 07:32:17 +00:00
if (scope.value)
Add default and converting constructors for all concrete Python types * Deprecate the `py::object::str()` member function since `py::str(obj)` is now equivalent and preferred * Make `py::repr()` a free function * Make sure obj.cast<T>() works as expected when T is a Python type `obj.cast<T>()` should be the same as `T(obj)`, i.e. it should convert the given object to a different Python type. However, `obj.cast<T>()` usually calls `type_caster::load()` which only checks the type without doing any actual conversion. That causes a very unexpected `cast_error`. This commit makes it so that `obj.cast<T>()` and `T(obj)` are the same when T is a Python type. * Simplify pytypes converting constructor implementation It's not necessary to maintain a full set of converting constructors and assignment operators + const& and &&. A single converting const& constructor will work and there is no impact on binary size. On the other hand, the conversion functions can be significantly simplified.
2016-10-25 20:12:39 +00:00
errorString += (std::string) str(scope.value);
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
include backtrace in pybind11::detail::error_string (#494)
2016-11-12 07:57:30 +00:00
PyErr_NormalizeException(&scope.type, &scope.value, &scope.trace);
detail::error_string: handle call stacks that switch between C++ and Python multiple times
2016-11-24 11:31:06 +00:00
#if PY_MAJOR_VERSION >= 3
if (scope.trace != nullptr)
PyException_SetTraceback(scope.value, scope.trace);
#endif
WIP: PyPy support (#527) This commit includes modifications that are needed to get pybind11 to work with PyPy. The full test suite compiles and runs except for a last few functions that are commented out (due to problems in PyPy that were reported on the PyPy bugtracker). Two somewhat intrusive changes were needed to make it possible: two new tags ``py::buffer_protocol()`` and ``py::metaclass()`` must now be specified to the ``class_`` constructor if the class uses the buffer protocol and/or requires a metaclass (e.g. for static properties). Note that this is only for the PyPy version based on Python 2.7 for now. When the PyPy 3.x has caught up in terms of cpyext compliance, a PyPy 3.x patch will follow.
2016-12-16 14:00:46 +00:00
#if !defined(PYPY_VERSION)
include backtrace in pybind11::detail::error_string (#494)
2016-11-12 07:57:30 +00:00
if (scope.trace) {
detail::error_string: handle call stacks that switch between C++ and Python multiple times
2016-11-24 11:31:06 +00:00
PyTracebackObject *trace = (PyTracebackObject *) scope.trace;
/* Get the deepest trace possible */
while (trace->tb_next)
trace = trace->tb_next;
PyFrameObject *frame = trace->tb_frame;
errorString += "\n\nAt:\n";
while (frame) {
int lineno = PyFrame_GetLineNumber(frame);
errorString +=
" " + handle(frame->f_code->co_filename).cast<std::string>() +
"(" + std::to_string(lineno) + "): " +
handle(frame->f_code->co_name).cast<std::string>() + "\n";
frame = frame->f_back;
include backtrace in pybind11::detail::error_string (#494)
2016-11-12 07:57:30 +00:00
}
}
WIP: PyPy support (#527) This commit includes modifications that are needed to get pybind11 to work with PyPy. The full test suite compiles and runs except for a last few functions that are commented out (due to problems in PyPy that were reported on the PyPy bugtracker). Two somewhat intrusive changes were needed to make it possible: two new tags ``py::buffer_protocol()`` and ``py::metaclass()`` must now be specified to the ``class_`` constructor if the class uses the buffer protocol and/or requires a metaclass (e.g. for static properties). Note that this is only for the PyPy version based on Python 2.7 for now. When the PyPy 3.x has caught up in terms of cpyext compliance, a PyPy 3.x patch will follow.
2016-12-16 14:00:46 +00:00
#endif
include backtrace in pybind11::detail::error_string (#494)
2016-11-12 07:57:30 +00:00
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
return errorString;
}
Track registered instances that share a pointer address The pointer to the first member of a class instance is the same as the pointer to instance itself; pybind11 has some workarounds for this to not track registered instances that have a registered parent with the same address. This doesn't work everywhere, however: issue #328 is a failure of this for a mutator operator which resolves its argument to the parent rather than the child, as is needed in #328. This commit resolves the issue (and restores tracking of same-address instances) by changing registered_instances from an unordered_map to an unordered_multimap that allows duplicate instances for the same pointer to be recorded, then resolves these differences by checking the type of each matched instance when looking up an instance. (A unordered_multimap seems cleaner for this than a unordered_map<list> or similar because, the vast majority of the time, the instance will be unique).
2016-08-09 21:57:59 +00:00
PYBIND11_NOINLINE inline handle get_object_handle(const void *ptr, const detail::type_info *type ) {
auto &instances = get_internals().registered_instances;
auto range = instances.equal_range(ptr);
for (auto it = range.first; it != range.second; ++it) {
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
for (auto vh : values_and_holders(it->second)) {
if (vh.type == type)
return handle((PyObject *) it->second);
}
Track registered instances that share a pointer address The pointer to the first member of a class instance is the same as the pointer to instance itself; pybind11 has some workarounds for this to not track registered instances that have a registered parent with the same address. This doesn't work everywhere, however: issue #328 is a failure of this for a mutator operator which resolves its argument to the parent rather than the child, as is needed in #328. This commit resolves the issue (and restores tracking of same-address instances) by changing registered_instances from an unordered_map to an unordered_multimap that allows duplicate instances for the same pointer to be recorded, then resolves these differences by checking the type of each matched instance when looking up an instance. (A unordered_multimap seems cleaner for this than a unordered_map<list> or similar because, the vast majority of the time, the instance will be unique).
2016-08-09 21:57:59 +00:00
}
return handle();
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
}
a few more GIL-related compatibility fixes
2016-04-25 13:02:43 +00:00
inline PyThreadState *get_thread_state_unchecked() {
WIP: PyPy support (#527) This commit includes modifications that are needed to get pybind11 to work with PyPy. The full test suite compiles and runs except for a last few functions that are commented out (due to problems in PyPy that were reported on the PyPy bugtracker). Two somewhat intrusive changes were needed to make it possible: two new tags ``py::buffer_protocol()`` and ``py::metaclass()`` must now be specified to the ``class_`` constructor if the class uses the buffer protocol and/or requires a metaclass (e.g. for static properties). Note that this is only for the PyPy version based on Python 2.7 for now. When the PyPy 3.x has caught up in terms of cpyext compliance, a PyPy 3.x patch will follow.
2016-12-16 14:00:46 +00:00
#if defined(PYPY_VERSION)
return PyThreadState_GET();
#elif PY_VERSION_HEX < 0x03000000
a few more GIL-related compatibility fixes
2016-04-25 13:02:43 +00:00
return _PyThreadState_Current;
#elif PY_VERSION_HEX < 0x03050000
return (PyThreadState*) _Py_atomic_load_relaxed(&_PyThreadState_Current);
#elif PY_VERSION_HEX < 0x03050200
return (PyThreadState*) _PyThreadState_Current.value;
#else
return _PyThreadState_UncheckedGet();
#endif
}
Expose more instance management functions This breaks up the instance management functions in class_support.h a little bit so that other pybind11 code can use it. In particular: - added make_new_instance() which does what pybind11_object_new does, but also allows instance allocation without `value` allocation. This lets `cast.h` use the same instance allocation rather than having its own separate implementation. - instance registration is now moved to a `register_instance()`/deregister_instance()` pair (rather than having individual code add or remove things from `registered_instances` directory). - clear_instance() does everything `pybind11_object_dealloc()` needs except for the deallocation; this is helpful for factory construction which needs to be able to replace the internals of an instance without deallocating it. - clear_instance() now also calls `dealloc` when `holder_constructed` is true, even if `value` is false. This can happen in factory construction when the pointer is moved from one instance to another, but the holder itself is only copied (i.e. for a shared_ptr holder).
2017-04-20 19:09:20 +00:00
// Forward declarations
Implement reference_internal with a keep_alive reference_internal requires an `instance` field to track the returned reference's parent, but that's just a duplication of what keep_alive<0,1> does, so use a keep alive to do this to eliminate the duplication.
2016-08-10 16:08:04 +00:00
inline void keep_alive_impl(handle nurse, handle patient);
Lazy instance value pointer allocation We currently allocate instance values when creating the instance itself (except when constructing the instance for a `cast()`), but there is no particular reason to do so: the instance itself and the internals (for a non-simple layout) are allocated via Python, with no reason to expect better locality from the invoked `operator new`. Moreover, it makes implementation of factory function constructors trickier and slightly less efficient: they don't use the pre-eallocate the memory, which means there is a pointless allocation and free. This commit makes the allocation lazy: instead of preallocating when creating the instance, the allocation happens when the instance is first loaded (if null at that time). In addition to making it more efficient to deal with cases that don't need preallocation, this also allows for a very slight performance increase by not needing to look up the instances types during allocation. (There is a lookup during the eventual load, of course, but that is happening already).
2017-08-01 03:32:34 +00:00
inline PyObject *make_new_instance(PyTypeObject *type);
Implement reference_internal with a keep_alive reference_internal requires an `instance` field to track the returned reference's parent, but that's just a duplication of what keep_alive<0,1> does, so use a keep alive to do this to eliminate the duplication.
2016-08-10 16:08:04 +00:00
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
class type_caster_generic {
public:
PYBIND11_NOINLINE type_caster_generic(const std::type_info &type_info)
Fix nullptr dereference when loading an external-only module_local type
2017-09-02 23:31:47 +00:00
: typeinfo(get_type_info(type_info)), cpptype(&type_info) { }
Initial commit
2015-07-05 18:05:44 +00:00
Fix nullptr dereference when loading an external-only module_local type
2017-09-02 23:31:47 +00:00
type_caster_generic(const type_info *typeinfo)
: typeinfo(typeinfo), cpptype(typeinfo ? typeinfo->cpptype : nullptr) { }
Allow module-local classes to be loaded externally The main point of `py::module_local` is to make the C++ -> Python cast unique so that returning/casting a C++ instance is well-defined. Unfortunately it also makes loading unique, but this isn't particularly desirable: when an instance contains `Type` instance there's no reason it shouldn't be possible to pass that instance to a bound function taking a `Type` parameter, even if that function is in another module. This commit solves the issue by allowing foreign module (and global) type loaders have a chance to load the value if the local module loader fails. The implementation here does this by storing a module-local loading function in a capsule in the python type, which we can then call if the local (and possibly global, if the local type is masking a global type) version doesn't work.
2017-08-17 15:38:05 +00:00
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
bool load(handle src, bool convert) {
return load_impl<type_caster_generic>(src, convert);
Initial commit
2015-07-05 18:05:44 +00:00
}
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
PYBIND11_NOINLINE static handle cast(const void *_src, return_value_policy policy, handle parent,
Fix downcasting of base class pointers When we are returned a base class pointer (either directly or via shared_from_this()) we detect its runtime type (using `typeid`), then end up essentially reinterpret_casting the pointer to the derived type. This is invalid when the base class pointer was a non-first base, and we end up with an invalid pointer. We could dynamic_cast to the most-derived type, but if *that* type isn't pybind11-registered, the resulting pointer given to the base `cast` implementation isn't necessarily valid to be reinterpret_cast'ed back to the backup type. This commit removes the "backup" type argument from the many-argument `cast(...)` and instead does the derived-or-pointer type decision and type lookup in type_caster_base, where the dynamic_cast has to be to correctly get the derived pointer, but also has to do the type lookup to ensure that we don't pass the wrong (derived) pointer when the backup type (i.e. the type caster intrinsic type) pointer is needed. Since the lookup is needed before calling the base cast(), this also changes the input type to a detail::type_info rather than doing a (second) lookup in cast().
2017-04-21 21:14:22 +00:00
const detail::type_info *tinfo,
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
void *(*copy_constructor)(const void *),
new move value policy
2016-04-25 21:04:27 +00:00
void *(*move_constructor)(const void *),
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
const void *existing_holder = nullptr) {
Fix downcasting of base class pointers When we are returned a base class pointer (either directly or via shared_from_this()) we detect its runtime type (using `typeid`), then end up essentially reinterpret_casting the pointer to the derived type. This is invalid when the base class pointer was a non-first base, and we end up with an invalid pointer. We could dynamic_cast to the most-derived type, but if *that* type isn't pybind11-registered, the resulting pointer given to the base `cast` implementation isn't necessarily valid to be reinterpret_cast'ed back to the backup type. This commit removes the "backup" type argument from the many-argument `cast(...)` and instead does the derived-or-pointer type decision and type lookup in type_caster_base, where the dynamic_cast has to be to correctly get the derived pointer, but also has to do the type lookup to ensure that we don't pass the wrong (derived) pointer when the backup type (i.e. the type caster intrinsic type) pointer is needed. Since the lookup is needed before calling the base cast(), this also changes the input type to a detail::type_info rather than doing a (second) lookup in cast().
2017-04-21 21:14:22 +00:00
if (!tinfo) // no type info: error will be set already
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
return handle();
Fix downcasting of base class pointers When we are returned a base class pointer (either directly or via shared_from_this()) we detect its runtime type (using `typeid`), then end up essentially reinterpret_casting the pointer to the derived type. This is invalid when the base class pointer was a non-first base, and we end up with an invalid pointer. We could dynamic_cast to the most-derived type, but if *that* type isn't pybind11-registered, the resulting pointer given to the base `cast` implementation isn't necessarily valid to be reinterpret_cast'ed back to the backup type. This commit removes the "backup" type argument from the many-argument `cast(...)` and instead does the derived-or-pointer type decision and type lookup in type_caster_base, where the dynamic_cast has to be to correctly get the derived pointer, but also has to do the type lookup to ensure that we don't pass the wrong (derived) pointer when the backup type (i.e. the type caster intrinsic type) pointer is needed. Since the lookup is needed before calling the base cast(), this also changes the input type to a detail::type_info rather than doing a (second) lookup in cast().
2017-04-21 21:14:22 +00:00
void *src = const_cast<void *>(_src);
if (src == nullptr)
return none().release();
Track registered instances that share a pointer address The pointer to the first member of a class instance is the same as the pointer to instance itself; pybind11 has some workarounds for this to not track registered instances that have a registered parent with the same address. This doesn't work everywhere, however: issue #328 is a failure of this for a mutator operator which resolves its argument to the parent rather than the child, as is needed in #328. This commit resolves the issue (and restores tracking of same-address instances) by changing registered_instances from an unordered_map to an unordered_multimap that allows duplicate instances for the same pointer to be recorded, then resolves these differences by checking the type of each matched instance when looking up an instance. (A unordered_multimap seems cleaner for this than a unordered_map<list> or similar because, the vast majority of the time, the instance will be unique).
2016-08-09 21:57:59 +00:00
Fix downcasting of base class pointers When we are returned a base class pointer (either directly or via shared_from_this()) we detect its runtime type (using `typeid`), then end up essentially reinterpret_casting the pointer to the derived type. This is invalid when the base class pointer was a non-first base, and we end up with an invalid pointer. We could dynamic_cast to the most-derived type, but if *that* type isn't pybind11-registered, the resulting pointer given to the base `cast` implementation isn't necessarily valid to be reinterpret_cast'ed back to the backup type. This commit removes the "backup" type argument from the many-argument `cast(...)` and instead does the derived-or-pointer type decision and type lookup in type_caster_base, where the dynamic_cast has to be to correctly get the derived pointer, but also has to do the type lookup to ensure that we don't pass the wrong (derived) pointer when the backup type (i.e. the type caster intrinsic type) pointer is needed. Since the lookup is needed before calling the base cast(), this also changes the input type to a detail::type_info rather than doing a (second) lookup in cast().
2017-04-21 21:14:22 +00:00
auto it_instances = get_internals().registered_instances.equal_range(src);
Silence MSVC warning PR #329 generates the following warning under MSVC: ...\cast.h(202): warning C4456: declaration of 'it' hides previous local declaration This renames the second iterator to silence it.
2016-08-11 20:23:23 +00:00
for (auto it_i = it_instances.first; it_i != it_instances.second; ++it_i) {
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
for (auto instance_type : detail::all_type_info(Py_TYPE(it_i->second))) {
Allow module-local classes to be loaded externally The main point of `py::module_local` is to make the C++ -> Python cast unique so that returning/casting a C++ instance is well-defined. Unfortunately it also makes loading unique, but this isn't particularly desirable: when an instance contains `Type` instance there's no reason it shouldn't be possible to pass that instance to a bound function taking a `Type` parameter, even if that function is in another module. This commit solves the issue by allowing foreign module (and global) type loaders have a chance to load the value if the local module loader fails. The implementation here does this by storing a module-local loading function in a capsule in the python type, which we can then call if the local (and possibly global, if the local type is masking a global type) version doesn't work.
2017-08-17 15:38:05 +00:00
if (instance_type && same_type(*instance_type->cpptype, *tinfo->cpptype))
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
return handle((PyObject *) it_i->second).inc_ref();
}
Track registered instances that share a pointer address The pointer to the first member of a class instance is the same as the pointer to instance itself; pybind11 has some workarounds for this to not track registered instances that have a registered parent with the same address. This doesn't work everywhere, however: issue #328 is a failure of this for a mutator operator which resolves its argument to the parent rather than the child, as is needed in #328. This commit resolves the issue (and restores tracking of same-address instances) by changing registered_instances from an unordered_map to an unordered_multimap that allows duplicate instances for the same pointer to be recorded, then resolves these differences by checking the type of each matched instance when looking up an instance. (A unordered_multimap seems cleaner for this than a unordered_map<list> or similar because, the vast majority of the time, the instance will be unique).
2016-08-09 21:57:59 +00:00
}
Lazy instance value pointer allocation We currently allocate instance values when creating the instance itself (except when constructing the instance for a `cast()`), but there is no particular reason to do so: the instance itself and the internals (for a non-simple layout) are allocated via Python, with no reason to expect better locality from the invoked `operator new`. Moreover, it makes implementation of factory function constructors trickier and slightly less efficient: they don't use the pre-eallocate the memory, which means there is a pointless allocation and free. This commit makes the allocation lazy: instead of preallocating when creating the instance, the allocation happens when the instance is first loaded (if null at that time). In addition to making it more efficient to deal with cases that don't need preallocation, this also allows for a very slight performance increase by not needing to look up the instances types during allocation. (There is a lookup during the eventual load, of course, but that is happening already).
2017-08-01 03:32:34 +00:00
auto inst = reinterpret_steal<object>(make_new_instance(tinfo->type));
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
auto wrapper = reinterpret_cast<instance *>(inst.ptr());
Fix wrapper's 'value' and 'owned' if ctor missing type_caster_generic::cast(): The values of wrapper->value wrapper->owned are incorrect in the case that a return value policy of 'copy' is requested but there is no copy-constructor. (Similarly 'move'.) In particular, if the source object is a static instance, the destructor of the 'object' 'inst' leads to class_::dealloc() which incorrectly attempts to 'delete' the static instance. This commit re-arranges the code to be clearer as to what the values of 'value' and 'owned' should be in the various cases. Behaviour is different to previous code only in two situations: policy = copy but no copy-ctor: Old code leaves 'value = src, owned = true', which leads to trouble. New code leaves 'value = nullptr, owned = false', which is correct. policy = move but no move- or copy-ctor: old code leaves 'value = src, owned = true', which leads to trouble. New code leaves 'value = nullptr, owned = false', which is correct.
2016-10-20 20:09:25 +00:00
wrapper->owned = false;
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
void *&valueptr = values_and_holders(wrapper).begin()->value_ptr();
Fix wrapper's 'value' and 'owned' if ctor missing type_caster_generic::cast(): The values of wrapper->value wrapper->owned are incorrect in the case that a return value policy of 'copy' is requested but there is no copy-constructor. (Similarly 'move'.) In particular, if the source object is a static instance, the destructor of the 'object' 'inst' leads to class_::dealloc() which incorrectly attempts to 'delete' the static instance. This commit re-arranges the code to be clearer as to what the values of 'value' and 'owned' should be in the various cases. Behaviour is different to previous code only in two situations: policy = copy but no copy-ctor: Old code leaves 'value = src, owned = true', which leads to trouble. New code leaves 'value = nullptr, owned = false', which is correct. policy = move but no move- or copy-ctor: old code leaves 'value = src, owned = true', which leads to trouble. New code leaves 'value = nullptr, owned = false', which is correct.
2016-10-20 20:09:25 +00:00
switch (policy) {
minor indentation change
2016-10-22 17:08:44 +00:00
case return_value_policy::automatic:
case return_value_policy::take_ownership:
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
valueptr = src;
minor indentation change
2016-10-22 17:08:44 +00:00
wrapper->owned = true;
break;
case return_value_policy::automatic_reference:
case return_value_policy::reference:
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
valueptr = src;
minor indentation change
2016-10-22 17:08:44 +00:00
wrapper->owned = false;
break;
case return_value_policy::copy:
if (copy_constructor)
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
valueptr = copy_constructor(src);
minor indentation change
2016-10-22 17:08:44 +00:00
else
throw cast_error("return_value_policy = copy, but the "
"object is non-copyable!");
wrapper->owned = true;
break;
case return_value_policy::move:
if (move_constructor)
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
valueptr = move_constructor(src);
minor indentation change
2016-10-22 17:08:44 +00:00
else if (copy_constructor)
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
valueptr = copy_constructor(src);
minor indentation change
2016-10-22 17:08:44 +00:00
else
throw cast_error("return_value_policy = move, but the "
"object is neither movable nor copyable!");
wrapper->owned = true;
break;
case return_value_policy::reference_internal:
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
valueptr = src;
minor indentation change
2016-10-22 17:08:44 +00:00
wrapper->owned = false;
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
keep_alive_impl(inst, parent);
minor indentation change
2016-10-22 17:08:44 +00:00
break;
default:
throw cast_error("unhandled return_value_policy: should not happen!");
Initial commit
2015-07-05 18:05:44 +00:00
}
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
Make `init_holder` do registration, and rename to `init_instance` The instance registration for offset base types fails (under macOS, with a segfault) in the presense of virtual base types. The issue occurs when trying to `static_cast<Base *>(derived_ptr)` when `derived_ptr` has been allocated (via `operator new`) but not initialized. This commit fixes the issue by moving the addition to `registered_instances` into `init_holder` rather than immediately after value pointer allocation. This also renames it to `init_instance` since it does more than holder initialization now. (I also further renamed `init_holder_helper` to `init_holder` since `init_holder` isn't used anymore). Fixes #959.
2017-07-25 04:53:23 +00:00
tinfo->init_instance(wrapper, existing_holder);
Track registered instances that share a pointer address The pointer to the first member of a class instance is the same as the pointer to instance itself; pybind11 has some workarounds for this to not track registered instances that have a registered parent with the same address. This doesn't work everywhere, however: issue #328 is a failure of this for a mutator operator which resolves its argument to the parent rather than the child, as is needed in #328. This commit resolves the issue (and restores tracking of same-address instances) by changing registered_instances from an unordered_map to an unordered_multimap that allows duplicate instances for the same pointer to be recorded, then resolves these differences by checking the type of each matched instance when looking up an instance. (A unordered_multimap seems cleaner for this than a unordered_map<list> or similar because, the vast majority of the time, the instance will be unique).
2016-08-09 21:57:59 +00:00
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
return inst.release();
Initial commit
2015-07-05 18:05:44 +00:00
}
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
// Base methods for generic caster; there are overridden in copyable_holder_caster
Lazy instance value pointer allocation We currently allocate instance values when creating the instance itself (except when constructing the instance for a `cast()`), but there is no particular reason to do so: the instance itself and the internals (for a non-simple layout) are allocated via Python, with no reason to expect better locality from the invoked `operator new`. Moreover, it makes implementation of factory function constructors trickier and slightly less efficient: they don't use the pre-eallocate the memory, which means there is a pointless allocation and free. This commit makes the allocation lazy: instead of preallocating when creating the instance, the allocation happens when the instance is first loaded (if null at that time). In addition to making it more efficient to deal with cases that don't need preallocation, this also allows for a very slight performance increase by not needing to look up the instances types during allocation. (There is a lookup during the eventual load, of course, but that is happening already).
2017-08-01 03:32:34 +00:00
void load_value(value_and_holder &&v_h) {
auto *&vptr = v_h.value_ptr();
// Lazy allocation for unallocated values:
if (vptr == nullptr) {
auto *type = v_h.type ? v_h.type : typeinfo;
Support C++17 aligned new statement (#1582) * Support C++17 aligned new statement This patch makes pybind11 aware of nonstandard alignment requirements in bound types and passes on this information to C++17 aligned 'new' operator. Pre-C++17, the behavior is unchanged.
2018-11-09 19:14:53 +00:00
if (type->operator_new) {
vptr = type->operator_new(type->type_size);
} else {
#if defined(PYBIND11_CPP17)
if (type->type_align > __STDCPP_DEFAULT_NEW_ALIGNMENT__)
vptr = ::operator new(type->type_size,
(std::align_val_t) type->type_align);
else
#endif
vptr = ::operator new(type->type_size);
}
Lazy instance value pointer allocation We currently allocate instance values when creating the instance itself (except when constructing the instance for a `cast()`), but there is no particular reason to do so: the instance itself and the internals (for a non-simple layout) are allocated via Python, with no reason to expect better locality from the invoked `operator new`. Moreover, it makes implementation of factory function constructors trickier and slightly less efficient: they don't use the pre-eallocate the memory, which means there is a pointless allocation and free. This commit makes the allocation lazy: instead of preallocating when creating the instance, the allocation happens when the instance is first loaded (if null at that time). In addition to making it more efficient to deal with cases that don't need preallocation, this also allows for a very slight performance increase by not needing to look up the instances types during allocation. (There is a lookup during the eventual load, of course, but that is happening already).
2017-08-01 03:32:34 +00:00
}
value = vptr;
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
}
bool try_implicit_casts(handle src, bool convert) {
for (auto &cast : typeinfo->implicit_casts) {
type_caster_generic sub_caster(*cast.first);
if (sub_caster.load(src, convert)) {
value = cast.second(sub_caster.value);
return true;
}
}
return false;
}
bool try_direct_conversions(handle src) {
for (auto &converter : *typeinfo->direct_conversions) {
if (converter(src.ptr(), value))
return true;
}
return false;
}
void check_holder_compat() {}
Allow module-local classes to be loaded externally The main point of `py::module_local` is to make the C++ -> Python cast unique so that returning/casting a C++ instance is well-defined. Unfortunately it also makes loading unique, but this isn't particularly desirable: when an instance contains `Type` instance there's no reason it shouldn't be possible to pass that instance to a bound function taking a `Type` parameter, even if that function is in another module. This commit solves the issue by allowing foreign module (and global) type loaders have a chance to load the value if the local module loader fails. The implementation here does this by storing a module-local loading function in a capsule in the python type, which we can then call if the local (and possibly global, if the local type is masking a global type) version doesn't work.
2017-08-17 15:38:05 +00:00
PYBIND11_NOINLINE static void *local_load(PyObject *src, const type_info *ti) {
auto caster = type_caster_generic(ti);
if (caster.load(src, false))
return caster.value;
return nullptr;
}
/// Try to load with foreign typeinfo, if available. Used when there is no
/// native typeinfo, or when the native one wasn't able to produce a value.
PYBIND11_NOINLINE bool try_load_foreign_module_local(handle src) {
Change internals ID and versioning scheme to avoid module conflicts The current PYBIND11_INTERNALS_ID depends on the version of the library in order to isolate binary incompatible internals capsules. However, this does not preclude conflicts between modules built from different (binary incompatible) commits with the same version number. For example, if one module was built with an early v2.2.dev and submitted to PyPI, it could not be loaded alongside a v2.2.x release module -- it would segfault because of incompatible internals with the same ID. This PR changes the ID to depend on PYBIND11_INTERNALS_VERSION which is independent of the main library version. It's an integer which should be incremented whenever a binary incompatible change is made to internals. PYBIND11_INTERNALS_KIND is also introduced for a similar reason. The same versioning scheme is also applied to `type_info` and the `module_local` type attribute.
2017-08-20 15:14:09 +00:00
constexpr auto *local_key = PYBIND11_MODULE_LOCAL_ID;
Allow module-local classes to be loaded externally The main point of `py::module_local` is to make the C++ -> Python cast unique so that returning/casting a C++ instance is well-defined. Unfortunately it also makes loading unique, but this isn't particularly desirable: when an instance contains `Type` instance there's no reason it shouldn't be possible to pass that instance to a bound function taking a `Type` parameter, even if that function is in another module. This commit solves the issue by allowing foreign module (and global) type loaders have a chance to load the value if the local module loader fails. The implementation here does this by storing a module-local loading function in a capsule in the python type, which we can then call if the local (and possibly global, if the local type is masking a global type) version doesn't work.
2017-08-17 15:38:05 +00:00
const auto pytype = src.get_type();
if (!hasattr(pytype, local_key))
return false;
type_info *foreign_typeinfo = reinterpret_borrow<capsule>(getattr(pytype, local_key));
// Only consider this foreign loader if actually foreign and is a loader of the correct cpp type
if (foreign_typeinfo->module_local_load == &local_load
Fix nullptr dereference when loading an external-only module_local type
2017-09-02 23:31:47 +00:00
|| (cpptype && !same_type(*cpptype, *foreign_typeinfo->cpptype)))
Allow module-local classes to be loaded externally The main point of `py::module_local` is to make the C++ -> Python cast unique so that returning/casting a C++ instance is well-defined. Unfortunately it also makes loading unique, but this isn't particularly desirable: when an instance contains `Type` instance there's no reason it shouldn't be possible to pass that instance to a bound function taking a `Type` parameter, even if that function is in another module. This commit solves the issue by allowing foreign module (and global) type loaders have a chance to load the value if the local module loader fails. The implementation here does this by storing a module-local loading function in a capsule in the python type, which we can then call if the local (and possibly global, if the local type is masking a global type) version doesn't work.
2017-08-17 15:38:05 +00:00
return false;
if (auto result = foreign_typeinfo->module_local_load(src.ptr(), foreign_typeinfo)) {
value = result;
return true;
}
return false;
}
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
// Implementation of `load`; this takes the type of `this` so that it can dispatch the relevant
// bits of code between here and copyable_holder_caster where the two classes need different
// logic (without having to resort to virtual inheritance).
template <typename ThisT>
PYBIND11_NOINLINE bool load_impl(handle src, bool convert) {
Allow module-local classes to be loaded externally The main point of `py::module_local` is to make the C++ -> Python cast unique so that returning/casting a C++ instance is well-defined. Unfortunately it also makes loading unique, but this isn't particularly desirable: when an instance contains `Type` instance there's no reason it shouldn't be possible to pass that instance to a bound function taking a `Type` parameter, even if that function is in another module. This commit solves the issue by allowing foreign module (and global) type loaders have a chance to load the value if the local module loader fails. The implementation here does this by storing a module-local loading function in a capsule in the python type, which we can then call if the local (and possibly global, if the local type is masking a global type) version doesn't work.
2017-08-17 15:38:05 +00:00
if (!src) return false;
if (!typeinfo) return try_load_foreign_module_local(src);
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
if (src.is_none()) {
// Defer accepting None to other overloads (if we aren't in convert mode):
if (!convert) return false;
value = nullptr;
return true;
}
auto &this_ = static_cast<ThisT &>(*this);
this_.check_holder_compat();
PyTypeObject *srctype = Py_TYPE(src.ptr());
// Case 1: If src is an exact type match for the target type then we can reinterpret_cast
// the instance's value pointer to the target type:
if (srctype == typeinfo->type) {
this_.load_value(reinterpret_cast<instance *>(src.ptr())->get_value_and_holder());
return true;
}
// Case 2: We have a derived class
else if (PyType_IsSubtype(srctype, typeinfo->type)) {
auto &bases = all_type_info(srctype);
bool no_cpp_mi = typeinfo->simple_type;
// Case 2a: the python type is a Python-inherited derived class that inherits from just
// one simple (no MI) pybind11 class, or is an exact match, so the C++ instance is of
// the right type and we can use reinterpret_cast.
// (This is essentially the same as case 2b, but because not using multiple inheritance
// is extremely common, we handle it specially to avoid the loop iterator and type
// pointer lookup overhead)
if (bases.size() == 1 && (no_cpp_mi || bases.front()->type == typeinfo->type)) {
this_.load_value(reinterpret_cast<instance *>(src.ptr())->get_value_and_holder());
return true;
}
// Case 2b: the python type inherits from multiple C++ bases. Check the bases to see if
// we can find an exact match (or, for a simple C++ type, an inherited match); if so, we
// can safely reinterpret_cast to the relevant pointer.
else if (bases.size() > 1) {
for (auto base : bases) {
if (no_cpp_mi ? PyType_IsSubtype(base->type, typeinfo->type) : base->type == typeinfo->type) {
this_.load_value(reinterpret_cast<instance *>(src.ptr())->get_value_and_holder(base));
return true;
}
}
}
// Case 2c: C++ multiple inheritance is involved and we couldn't find an exact type match
// in the registered bases, above, so try implicit casting (needed for proper C++ casting
// when MI is involved).
if (this_.try_implicit_casts(src, convert))
return true;
}
// Perform an implicit conversion
if (convert) {
for (auto &converter : typeinfo->implicit_conversions) {
Add a life support system for type_caster temporaries
2017-06-26 18:34:06 +00:00
auto temp = reinterpret_steal<object>(converter(src.ptr(), typeinfo->type));
if (load_impl<ThisT>(temp, false)) {
loader_life_support::add_patient(temp);
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
return true;
Add a life support system for type_caster temporaries
2017-06-26 18:34:06 +00:00
}
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
}
if (this_.try_direct_conversions(src))
return true;
}
Allow module-local classes to be loaded externally The main point of `py::module_local` is to make the C++ -> Python cast unique so that returning/casting a C++ instance is well-defined. Unfortunately it also makes loading unique, but this isn't particularly desirable: when an instance contains `Type` instance there's no reason it shouldn't be possible to pass that instance to a bound function taking a `Type` parameter, even if that function is in another module. This commit solves the issue by allowing foreign module (and global) type loaders have a chance to load the value if the local module loader fails. The implementation here does this by storing a module-local loading function in a capsule in the python type, which we can then call if the local (and possibly global, if the local type is masking a global type) version doesn't work.
2017-08-17 15:38:05 +00:00
// Failed to match local typeinfo. Try again with global.
if (typeinfo->module_local) {
if (auto gtype = get_global_type_info(*typeinfo->cpptype)) {
typeinfo = gtype;
return load(src, false);
}
}
// Global typeinfo has precedence over foreign module_local
return try_load_foreign_module_local(src);
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
}
Fix downcasting of base class pointers When we are returned a base class pointer (either directly or via shared_from_this()) we detect its runtime type (using `typeid`), then end up essentially reinterpret_casting the pointer to the derived type. This is invalid when the base class pointer was a non-first base, and we end up with an invalid pointer. We could dynamic_cast to the most-derived type, but if *that* type isn't pybind11-registered, the resulting pointer given to the base `cast` implementation isn't necessarily valid to be reinterpret_cast'ed back to the backup type. This commit removes the "backup" type argument from the many-argument `cast(...)` and instead does the derived-or-pointer type decision and type lookup in type_caster_base, where the dynamic_cast has to be to correctly get the derived pointer, but also has to do the type lookup to ensure that we don't pass the wrong (derived) pointer when the backup type (i.e. the type caster intrinsic type) pointer is needed. Since the lookup is needed before calling the base cast(), this also changes the input type to a detail::type_info rather than doing a (second) lookup in cast().
2017-04-21 21:14:22 +00:00
// Called to do type lookup and wrap the pointer and type in a pair when a dynamic_cast
// isn't needed or can't be used. If the type is unknown, sets the error and returns a pair
// with .second = nullptr. (p.first = nullptr is not an error: it becomes None).
PYBIND11_NOINLINE static std::pair<const void *, const type_info *> src_and_type(
Use std::type_info::name() for type lookups outside stdlibc++ Using `std::type_info::operator==` fails under libc++ because the .so is loaded with RTLD_LOCAL. libc++ considers types under such .sos distinct, and so comparing typeid() values directly isn't going to work. This adds a custom hasher and equality class for the type lookup maps when not under stdlibc++, and adds a `detail::same_type` function to perform the equality test. It also converts a few pointer arguments to const lvalue references, particularly since doing the pointer comparison wasn't technically valid to being with (though in practice, appeared to work everywhere). This fixes #912.
2017-06-21 17:38:10 +00:00
const void *src, const std::type_info &cast_type, const std::type_info *rtti_type = nullptr) {
Add py::module_local() attribute for module-local type bindings This commit adds a `py::module_local` attribute that lets you confine a registered type to the module (more technically, the shared object) in which it is defined, by registering it with: py::class_<C>(m, "C", py::module_local()) This will allow the same C++ class `C` to be registered in different modules with independent sets of class definitions. On the Python side, two such types will be completely distinct; on the C++ side, the C++ type resolves to a different Python type in each module. This applies `py::module_local` automatically to `stl_bind.h` bindings when the container value type looks like something global: i.e. when it is a converting type (for example, when binding a `std::vector<int>`), or when it is a registered type itself bound with `py::module_local`. This should help resolve potential future conflicts (e.g. if two completely unrelated modules both try to bind a `std::vector<int>`. Users can override the automatic selection by adding a `py::module_local()` or `py::module_local(false)`. Note that this does mildly break backwards compatibility: bound stl containers of basic types like `std::vector<int>` cannot be bound in one module and returned in a different module. (This can be re-enabled with `py::module_local(false)` as described above, but with the potential for eventual load conflicts).
2017-07-29 02:03:44 +00:00
if (auto *tpi = get_type_info(cast_type))
return {src, const_cast<const type_info *>(tpi)};
Fix downcasting of base class pointers When we are returned a base class pointer (either directly or via shared_from_this()) we detect its runtime type (using `typeid`), then end up essentially reinterpret_casting the pointer to the derived type. This is invalid when the base class pointer was a non-first base, and we end up with an invalid pointer. We could dynamic_cast to the most-derived type, but if *that* type isn't pybind11-registered, the resulting pointer given to the base `cast` implementation isn't necessarily valid to be reinterpret_cast'ed back to the backup type. This commit removes the "backup" type argument from the many-argument `cast(...)` and instead does the derived-or-pointer type decision and type lookup in type_caster_base, where the dynamic_cast has to be to correctly get the derived pointer, but also has to do the type lookup to ensure that we don't pass the wrong (derived) pointer when the backup type (i.e. the type caster intrinsic type) pointer is needed. Since the lookup is needed before calling the base cast(), this also changes the input type to a detail::type_info rather than doing a (second) lookup in cast().
2017-04-21 21:14:22 +00:00
// Not found, set error:
Use std::type_info::name() for type lookups outside stdlibc++ Using `std::type_info::operator==` fails under libc++ because the .so is loaded with RTLD_LOCAL. libc++ considers types under such .sos distinct, and so comparing typeid() values directly isn't going to work. This adds a custom hasher and equality class for the type lookup maps when not under stdlibc++, and adds a `detail::same_type` function to perform the equality test. It also converts a few pointer arguments to const lvalue references, particularly since doing the pointer comparison wasn't technically valid to being with (though in practice, appeared to work everywhere). This fixes #912.
2017-06-21 17:38:10 +00:00
std::string tname = rtti_type ? rtti_type->name() : cast_type.name();
Fix downcasting of base class pointers When we are returned a base class pointer (either directly or via shared_from_this()) we detect its runtime type (using `typeid`), then end up essentially reinterpret_casting the pointer to the derived type. This is invalid when the base class pointer was a non-first base, and we end up with an invalid pointer. We could dynamic_cast to the most-derived type, but if *that* type isn't pybind11-registered, the resulting pointer given to the base `cast` implementation isn't necessarily valid to be reinterpret_cast'ed back to the backup type. This commit removes the "backup" type argument from the many-argument `cast(...)` and instead does the derived-or-pointer type decision and type lookup in type_caster_base, where the dynamic_cast has to be to correctly get the derived pointer, but also has to do the type lookup to ensure that we don't pass the wrong (derived) pointer when the backup type (i.e. the type caster intrinsic type) pointer is needed. Since the lookup is needed before calling the base cast(), this also changes the input type to a detail::type_info rather than doing a (second) lookup in cast().
2017-04-21 21:14:22 +00:00
detail::clean_type_id(tname);
std::string msg = "Unregistered type : " + tname;
PyErr_SetString(PyExc_TypeError, msg.c_str());
return {nullptr, nullptr};
}
Initial commit
2015-07-05 18:05:44 +00:00
const type_info *typeinfo = nullptr;
Fix nullptr dereference when loading an external-only module_local type
2017-09-02 23:31:47 +00:00
const std::type_info *cpptype = nullptr;
factored out some common functionality to a non-templated parent class
2015-10-19 21:50:51 +00:00
void *value = nullptr;
Initial commit
2015-07-05 18:05:44 +00:00
};
Add movable cast support to type casters This commit allows type_casters to allow their local values to be moved away, rather than copied, when the type caster instance itself is an rvalue. This only applies (automatically) to type casters using PYBIND11_TYPE_CASTER; the generic type type casters don't own their own pointer, and various value casters (e.g. std::string, std::pair, arithmetic types) already cast to an rvalue (i.e. they return by value). This updates various calling code to attempt to get a movable value whenever the value is itself coming from a type caster about to be destroyed: for example, when constructing an std::pair or various stl.h containers. For types that don't support value moving, the cast_op falls back to an lvalue cast. There wasn't an obvious place to add the tests, so I added them to test_copy_move_policies, but also renamed it to drop the _policies as it now tests more than just policies.
2017-05-14 19:57:26 +00:00
/**
* Determine suitable casting operator for pointer-or-lvalue-casting type casters. The type caster
* needs to provide `operator T*()` and `operator T&()` operators.
*
* If the type supports moving the value away via an `operator T&&() &&` method, it should use
* `movable_cast_op_type` instead.
*/
modularized logic in preceding change, fixed issue with char (fixes #150)
2016-03-26 22:04:10 +00:00
template <typename T>
Add movable cast support to type casters This commit allows type_casters to allow their local values to be moved away, rather than copied, when the type caster instance itself is an rvalue. This only applies (automatically) to type casters using PYBIND11_TYPE_CASTER; the generic type type casters don't own their own pointer, and various value casters (e.g. std::string, std::pair, arithmetic types) already cast to an rvalue (i.e. they return by value). This updates various calling code to attempt to get a movable value whenever the value is itself coming from a type caster about to be destroyed: for example, when constructing an std::pair or various stl.h containers. For types that don't support value moving, the cast_op falls back to an lvalue cast. There wasn't an obvious place to add the tests, so I added them to test_copy_move_policies, but also renamed it to drop the _policies as it now tests more than just policies.
2017-05-14 19:57:26 +00:00
using cast_op_type =
Add and use detail::remove_reference_t Adds `remove_reference_t` and converts various `typename std::remove_reference<...>::type` to using it.
2017-03-26 03:01:52 +00:00
conditional_t<std::is_pointer<remove_reference_t<T>>::value,
Add movable cast support to type casters This commit allows type_casters to allow their local values to be moved away, rather than copied, when the type caster instance itself is an rvalue. This only applies (automatically) to type casters using PYBIND11_TYPE_CASTER; the generic type type casters don't own their own pointer, and various value casters (e.g. std::string, std::pair, arithmetic types) already cast to an rvalue (i.e. they return by value). This updates various calling code to attempt to get a movable value whenever the value is itself coming from a type caster about to be destroyed: for example, when constructing an std::pair or various stl.h containers. For types that don't support value moving, the cast_op falls back to an lvalue cast. There wasn't an obvious place to add the tests, so I added them to test_copy_move_policies, but also renamed it to drop the _policies as it now tests more than just policies.
2017-05-14 19:57:26 +00:00
typename std::add_pointer<intrinsic_t<T>>::type,
typename std::add_lvalue_reference<intrinsic_t<T>>::type>;
/**
* Determine suitable casting operator for a type caster with a movable value. Such a type caster
* needs to provide `operator T*()`, `operator T&()`, and `operator T&&() &&`. The latter will be
* called in appropriate contexts where the value can be moved rather than copied.
*
* These operator are automatically provided when using the PYBIND11_TYPE_CASTER macro.
*/
template <typename T>
using movable_cast_op_type =
conditional_t<std::is_pointer<typename std::remove_reference<T>::type>::value,
typename std::add_pointer<intrinsic_t<T>>::type,
conditional_t<std::is_rvalue_reference<T>::value,
typename std::add_rvalue_reference<intrinsic_t<T>>::type,
typename std::add_lvalue_reference<intrinsic_t<T>>::type>>;
modularized logic in preceding change, fixed issue with char (fixes #150)
2016-03-26 22:04:10 +00:00
Fix stl_bind to support movable, non-copyable value types (#490) This commit includes the following changes: * Don't provide make_copy_constructor for non-copyable container make_copy_constructor currently fails for various stl containers (e.g. std::vector, std::unordered_map, std::deque, etc.) when the container's value type (e.g. the "T" or the std::pair<K,T> for a map) is non-copyable. This adds an override that, for types that look like containers, also requires that the value_type be copyable. * stl_bind.h: make bind_{vector,map} work for non-copy-constructible types Most stl_bind modifiers require copying, so if the type isn't copy constructible, we provide a read-only interface instead. In practice, this means that if the type is non-copyable, it will be, for all intents and purposes, read-only from the Python side (but currently it simply fails to compile with such a container). It is still possible for the caller to provide an interface manually (by defining methods on the returned class_ object), but this isn't something stl_bind can handle because the C++ code to construct values is going to be highly dependent on the container value_type. * stl_bind: copy only for arithmetic value types For non-primitive types, we may well be copying some complex type, when returning by reference is more appropriate. This commit returns by internal reference for all but basic arithmetic types. * Return by reference whenever possible Only if we definitely can't--i.e. std::vector<bool>--because v[i] returns something that isn't a T& do we copy; for everything else, we return by reference. For the map case, we can always return by reference (at least for the default stl map/unordered_map).
2016-11-15 11:30:38 +00:00
// std::is_copy_constructible isn't quite enough: it lets std::vector<T> (and similar) through when
// T is non-copyable, but code containing such a copy constructor fails to actually compile.
template <typename T, typename SFINAE = void> struct is_copy_constructible : std::is_copy_constructible<T> {};
// Specialization for types that appear to be copy constructible but also look like stl containers
// (we specifically check for: has `value_type` and `reference` with `reference = value_type&`): if
// so, copy constructability depends on whether the value_type is copy constructible.
Detect std::pair non-copyability Pre-C++17, std::pair can technically have an copy constructor even though it can't actually be invoked without a compilation failure (due to the underlying types being non-copyable). Most stls, including libc++ since ~3.4, use the C++17 behaviour of not exposing an uncallable copy constructor, but FreeBSD deliberately broke their libc++ to preserve the nonsensical behaviour (https://svnweb.freebsd.org/base?view=revision&revision=261801). This updates pybind's internal `is_copy_constructible` to also detect the std::pair case under pre-C++17. This also everything (except for a couple cases in the internal version) to use the internal `is_copy_constructible` rather than `std::is_copy_constructible`.
2017-07-27 18:55:17 +00:00
template <typename Container> struct is_copy_constructible<Container, enable_if_t<all_of<
std::is_copy_constructible<Container>,
std::is_same<typename Container::value_type &, typename Container::reference>
>::value>> : is_copy_constructible<typename Container::value_type> {};
#if !defined(PYBIND11_CPP17)
// Likewise for std::pair before C++17 (which mandates that the copy constructor not exist when the
// two types aren't themselves copy constructible).
template <typename T1, typename T2> struct is_copy_constructible<std::pair<T1, T2>>
: all_of<is_copy_constructible<T1>, is_copy_constructible<T2>> {};
#endif
Fix stl_bind to support movable, non-copyable value types (#490) This commit includes the following changes: * Don't provide make_copy_constructor for non-copyable container make_copy_constructor currently fails for various stl containers (e.g. std::vector, std::unordered_map, std::deque, etc.) when the container's value type (e.g. the "T" or the std::pair<K,T> for a map) is non-copyable. This adds an override that, for types that look like containers, also requires that the value_type be copyable. * stl_bind.h: make bind_{vector,map} work for non-copy-constructible types Most stl_bind modifiers require copying, so if the type isn't copy constructible, we provide a read-only interface instead. In practice, this means that if the type is non-copyable, it will be, for all intents and purposes, read-only from the Python side (but currently it simply fails to compile with such a container). It is still possible for the caller to provide an interface manually (by defining methods on the returned class_ object), but this isn't something stl_bind can handle because the C++ code to construct values is going to be highly dependent on the container value_type. * stl_bind: copy only for arithmetic value types For non-primitive types, we may well be copying some complex type, when returning by reference is more appropriate. This commit returns by internal reference for all but basic arithmetic types. * Return by reference whenever possible Only if we definitely can't--i.e. std::vector<bool>--because v[i] returns something that isn't a T& do we copy; for everything else, we return by reference. For the map case, we can always return by reference (at least for the default stl map/unordered_map).
2016-11-15 11:30:38 +00:00
Add basic support for tag-based static polymorphism (#1326) * Add basic support for tag-based static polymorphism Sometimes it is possible to look at a C++ object and know what its dynamic type is, even if it doesn't use C++ polymorphism, because instances of the object and its subclasses conform to some other mechanism for being self-describing; for example, perhaps there's an enumerated "tag" or "kind" member in the base class that's always set to an indication of the correct type. This might be done for performance reasons, or to permit most-derived types to be trivially copyable. One of the most widely-known examples is in LLVM: https://llvm.org/docs/HowToSetUpLLVMStyleRTTI.html This PR permits pybind11 to be informed of such conventions via a new specializable detail::polymorphic_type_hook<> template, which generalizes the previous logic for determining the runtime type of an object based on C++ RTTI. Implementors provide a way to map from a base class object to a const std::type_info* for the dynamic type; pybind11 then uses this to ensure that casting a Base* to Python creates a Python object that knows it's wrapping the appropriate sort of Derived. There are a number of restrictions with this tag-based static polymorphism support compared to pybind11's existing support for built-in C++ polymorphism: - there is no support for this-pointer adjustment, so only single inheritance is permitted - there is no way to make C++ code call new Python-provided subclasses - when binding C++ classes that redefine a method in a subclass, the .def() must be repeated in the binding for Python to know about the update But these are not much of an issue in practice in many cases, the impact on the complexity of pybind11's innards is minimal and localized, and the support for automatic downcasting improves usability a great deal.
2018-04-14 00:13:10 +00:00
NAMESPACE_END(detail)
// polymorphic_type_hook<itype>::get(src, tinfo) determines whether the object pointed
// to by `src` actually is an instance of some class derived from `itype`.
// If so, it sets `tinfo` to point to the std::type_info representing that derived
// type, and returns a pointer to the start of the most-derived object of that type
// (in which `src` is a subobject; this will be the same address as `src` in most
// single inheritance cases). If not, or if `src` is nullptr, it simply returns `src`
// and leaves `tinfo` at its default value of nullptr.
//
// The default polymorphic_type_hook just returns src. A specialization for polymorphic
// types determines the runtime type of the passed object and adjusts the this-pointer
// appropriately via dynamic_cast<void*>. This is what enables a C++ Animal* to appear
// to Python as a Dog (if Dog inherits from Animal, Animal is polymorphic, Dog is
// registered with pybind11, and this Animal is in fact a Dog).
//
// You may specialize polymorphic_type_hook yourself for types that want to appear
// polymorphic to Python but do not use C++ RTTI. (This is a not uncommon pattern
// in performance-sensitive applications, used most notably in LLVM.)
template <typename itype, typename SFINAE = void>
struct polymorphic_type_hook
{
static const void *get(const itype *src, const std::type_info*&) { return src; }
};
template <typename itype>
struct polymorphic_type_hook<itype, detail::enable_if_t<std::is_polymorphic<itype>::value>>
{
static const void *get(const itype *src, const std::type_info*& type) {
type = src ? &typeid(*src) : nullptr;
return dynamic_cast<const void*>(src);
}
};
NAMESPACE_BEGIN(detail)
factored out some common functionality to a non-templated parent class
2015-10-19 21:50:51 +00:00
/// Generic type caster for objects stored on the heap
opaque type redesign
2016-04-28 14:25:24 +00:00
template <typename type> class type_caster_base : public type_caster_generic {
Fix type caster for heap reference types Need to use the intrinsic type, not the raw type. Fixes #392.
2016-09-07 17:32:49 +00:00
using itype = intrinsic_t<type>;
Add basic support for tag-based static polymorphism (#1326) * Add basic support for tag-based static polymorphism Sometimes it is possible to look at a C++ object and know what its dynamic type is, even if it doesn't use C++ polymorphism, because instances of the object and its subclasses conform to some other mechanism for being self-describing; for example, perhaps there's an enumerated "tag" or "kind" member in the base class that's always set to an indication of the correct type. This might be done for performance reasons, or to permit most-derived types to be trivially copyable. One of the most widely-known examples is in LLVM: https://llvm.org/docs/HowToSetUpLLVMStyleRTTI.html This PR permits pybind11 to be informed of such conventions via a new specializable detail::polymorphic_type_hook<> template, which generalizes the previous logic for determining the runtime type of an object based on C++ RTTI. Implementors provide a way to map from a base class object to a const std::type_info* for the dynamic type; pybind11 then uses this to ensure that casting a Base* to Python creates a Python object that knows it's wrapping the appropriate sort of Derived. There are a number of restrictions with this tag-based static polymorphism support compared to pybind11's existing support for built-in C++ polymorphism: - there is no support for this-pointer adjustment, so only single inheritance is permitted - there is no way to make C++ code call new Python-provided subclasses - when binding C++ classes that redefine a method in a subclass, the .def() must be repeated in the binding for Python to know about the update But these are not much of an issue in practice in many cases, the impact on the complexity of pybind11's innards is minimal and localized, and the support for automatic downcasting improves usability a great deal.
2018-04-14 00:13:10 +00:00
factored out some common functionality to a non-templated parent class
2015-10-19 21:50:51 +00:00
public:
Simplify function signature annotation and parsing `type_descr` is now applied only to the final signature so that it only marks the argument types, but not nested types (e.g. for tuples) or return types.
2017-08-31 12:38:23 +00:00
static constexpr auto name = _<type>();
factored out some common functionality to a non-templated parent class
2015-10-19 21:50:51 +00:00
Multiple inheritance support
2016-09-11 11:00:40 +00:00
type_caster_base() : type_caster_base(typeid(type)) { }
Disable most implicit conversion constructors We have various classes that have non-explicit constructors that accept a single argument, which is implicitly making them implicitly convertible from the argument. In a few cases, this is desirable (e.g. implicit conversion of std::string to py::str, or conversion of double to py::float_); in many others, however, it is unintended (e.g. implicit conversion of size_t to some pre-declared py::array_t<T> type). This disables most of the unwanted implicit conversions by marking them `explicit`, and comments the ones that are deliberately left implicit.
2016-10-16 20:27:42 +00:00
explicit type_caster_base(const std::type_info &info) : type_caster_generic(info) { }
factored out some common functionality to a non-templated parent class
2015-10-19 21:50:51 +00:00
Fix type caster for heap reference types Need to use the intrinsic type, not the raw type. Fixes #392.
2016-09-07 17:32:49 +00:00
static handle cast(const itype &src, return_value_policy policy, handle parent) {
New automatic return value policy for cat() and make_tuple(), fixed an ambiguity issue
2016-04-14 12:26:13 +00:00
if (policy == return_value_policy::automatic || policy == return_value_policy::automatic_reference)
factored out some common functionality to a non-templated parent class
2015-10-19 21:50:51 +00:00
policy = return_value_policy::copy;
return best representation of polymorphic types (fixes #105)
2016-04-13 11:45:09 +00:00
return cast(&src, policy, parent);
factored out some common functionality to a non-templated parent class
2015-10-19 21:50:51 +00:00
}
Always use return_value_policy::move for rvalues (#510) Fixes #509. The move policy was already set for rvalues in PR #473, but this only applied to directly cast user-defined types. The problem is that STL containers cast values indirectly and the rvalue information is lost. Therefore the move policy was not set correctly. This commit fixes it. This also makes an additional adjustment to remove the `copy` policy exception: rvalues now always use the `move` policy. This is also safe for copy-only rvalues because the `move` policy has an internal fallback to copying.
2016-11-20 04:31:02 +00:00
static handle cast(itype &&src, return_value_policy, handle parent) {
return cast(&src, return_value_policy::move, parent);
new move value policy
2016-04-25 21:04:27 +00:00
}
Add basic support for tag-based static polymorphism (#1326) * Add basic support for tag-based static polymorphism Sometimes it is possible to look at a C++ object and know what its dynamic type is, even if it doesn't use C++ polymorphism, because instances of the object and its subclasses conform to some other mechanism for being self-describing; for example, perhaps there's an enumerated "tag" or "kind" member in the base class that's always set to an indication of the correct type. This might be done for performance reasons, or to permit most-derived types to be trivially copyable. One of the most widely-known examples is in LLVM: https://llvm.org/docs/HowToSetUpLLVMStyleRTTI.html This PR permits pybind11 to be informed of such conventions via a new specializable detail::polymorphic_type_hook<> template, which generalizes the previous logic for determining the runtime type of an object based on C++ RTTI. Implementors provide a way to map from a base class object to a const std::type_info* for the dynamic type; pybind11 then uses this to ensure that casting a Base* to Python creates a Python object that knows it's wrapping the appropriate sort of Derived. There are a number of restrictions with this tag-based static polymorphism support compared to pybind11's existing support for built-in C++ polymorphism: - there is no support for this-pointer adjustment, so only single inheritance is permitted - there is no way to make C++ code call new Python-provided subclasses - when binding C++ classes that redefine a method in a subclass, the .def() must be repeated in the binding for Python to know about the update But these are not much of an issue in practice in many cases, the impact on the complexity of pybind11's innards is minimal and localized, and the support for automatic downcasting improves usability a great deal.
2018-04-14 00:13:10 +00:00
// Returns a (pointer, type_info) pair taking care of necessary type lookup for a
// polymorphic type (using RTTI by default, but can be overridden by specializing
// polymorphic_type_hook). If the instance isn't derived, returns the base version.
Fix downcasting of base class pointers When we are returned a base class pointer (either directly or via shared_from_this()) we detect its runtime type (using `typeid`), then end up essentially reinterpret_casting the pointer to the derived type. This is invalid when the base class pointer was a non-first base, and we end up with an invalid pointer. We could dynamic_cast to the most-derived type, but if *that* type isn't pybind11-registered, the resulting pointer given to the base `cast` implementation isn't necessarily valid to be reinterpret_cast'ed back to the backup type. This commit removes the "backup" type argument from the many-argument `cast(...)` and instead does the derived-or-pointer type decision and type lookup in type_caster_base, where the dynamic_cast has to be to correctly get the derived pointer, but also has to do the type lookup to ensure that we don't pass the wrong (derived) pointer when the backup type (i.e. the type caster intrinsic type) pointer is needed. Since the lookup is needed before calling the base cast(), this also changes the input type to a detail::type_info rather than doing a (second) lookup in cast().
2017-04-21 21:14:22 +00:00
static std::pair<const void *, const type_info *> src_and_type(const itype *src) {
Use std::type_info::name() for type lookups outside stdlibc++ Using `std::type_info::operator==` fails under libc++ because the .so is loaded with RTLD_LOCAL. libc++ considers types under such .sos distinct, and so comparing typeid() values directly isn't going to work. This adds a custom hasher and equality class for the type lookup maps when not under stdlibc++, and adds a `detail::same_type` function to perform the equality test. It also converts a few pointer arguments to const lvalue references, particularly since doing the pointer comparison wasn't technically valid to being with (though in practice, appeared to work everywhere). This fixes #912.
2017-06-21 17:38:10 +00:00
auto &cast_type = typeid(itype);
Fix downcasting of base class pointers When we are returned a base class pointer (either directly or via shared_from_this()) we detect its runtime type (using `typeid`), then end up essentially reinterpret_casting the pointer to the derived type. This is invalid when the base class pointer was a non-first base, and we end up with an invalid pointer. We could dynamic_cast to the most-derived type, but if *that* type isn't pybind11-registered, the resulting pointer given to the base `cast` implementation isn't necessarily valid to be reinterpret_cast'ed back to the backup type. This commit removes the "backup" type argument from the many-argument `cast(...)` and instead does the derived-or-pointer type decision and type lookup in type_caster_base, where the dynamic_cast has to be to correctly get the derived pointer, but also has to do the type lookup to ensure that we don't pass the wrong (derived) pointer when the backup type (i.e. the type caster intrinsic type) pointer is needed. Since the lookup is needed before calling the base cast(), this also changes the input type to a detail::type_info rather than doing a (second) lookup in cast().
2017-04-21 21:14:22 +00:00
const std::type_info *instance_type = nullptr;
Add basic support for tag-based static polymorphism (#1326) * Add basic support for tag-based static polymorphism Sometimes it is possible to look at a C++ object and know what its dynamic type is, even if it doesn't use C++ polymorphism, because instances of the object and its subclasses conform to some other mechanism for being self-describing; for example, perhaps there's an enumerated "tag" or "kind" member in the base class that's always set to an indication of the correct type. This might be done for performance reasons, or to permit most-derived types to be trivially copyable. One of the most widely-known examples is in LLVM: https://llvm.org/docs/HowToSetUpLLVMStyleRTTI.html This PR permits pybind11 to be informed of such conventions via a new specializable detail::polymorphic_type_hook<> template, which generalizes the previous logic for determining the runtime type of an object based on C++ RTTI. Implementors provide a way to map from a base class object to a const std::type_info* for the dynamic type; pybind11 then uses this to ensure that casting a Base* to Python creates a Python object that knows it's wrapping the appropriate sort of Derived. There are a number of restrictions with this tag-based static polymorphism support compared to pybind11's existing support for built-in C++ polymorphism: - there is no support for this-pointer adjustment, so only single inheritance is permitted - there is no way to make C++ code call new Python-provided subclasses - when binding C++ classes that redefine a method in a subclass, the .def() must be repeated in the binding for Python to know about the update But these are not much of an issue in practice in many cases, the impact on the complexity of pybind11's innards is minimal and localized, and the support for automatic downcasting improves usability a great deal.
2018-04-14 00:13:10 +00:00
const void *vsrc = polymorphic_type_hook<itype>::get(src, instance_type);
if (instance_type && !same_type(cast_type, *instance_type)) {
// This is a base pointer to a derived type. If the derived type is registered
// with pybind11, we want to make the full derived object available.
// In the typical case where itype is polymorphic, we get the correct
// derived pointer (which may be != base pointer) by a dynamic_cast to
// most derived type. If itype is not polymorphic, we won't get here
// except via a user-provided specialization of polymorphic_type_hook,
// and the user has promised that no this-pointer adjustment is
// required in that case, so it's OK to use static_cast.
if (const auto *tpi = get_type_info(*instance_type))
return {vsrc, tpi};
Fix downcasting of base class pointers When we are returned a base class pointer (either directly or via shared_from_this()) we detect its runtime type (using `typeid`), then end up essentially reinterpret_casting the pointer to the derived type. This is invalid when the base class pointer was a non-first base, and we end up with an invalid pointer. We could dynamic_cast to the most-derived type, but if *that* type isn't pybind11-registered, the resulting pointer given to the base `cast` implementation isn't necessarily valid to be reinterpret_cast'ed back to the backup type. This commit removes the "backup" type argument from the many-argument `cast(...)` and instead does the derived-or-pointer type decision and type lookup in type_caster_base, where the dynamic_cast has to be to correctly get the derived pointer, but also has to do the type lookup to ensure that we don't pass the wrong (derived) pointer when the backup type (i.e. the type caster intrinsic type) pointer is needed. Since the lookup is needed before calling the base cast(), this also changes the input type to a detail::type_info rather than doing a (second) lookup in cast().
2017-04-21 21:14:22 +00:00
}
// Otherwise we have either a nullptr, an `itype` pointer, or an unknown derived pointer, so
// don't do a cast
Add basic support for tag-based static polymorphism (#1326) * Add basic support for tag-based static polymorphism Sometimes it is possible to look at a C++ object and know what its dynamic type is, even if it doesn't use C++ polymorphism, because instances of the object and its subclasses conform to some other mechanism for being self-describing; for example, perhaps there's an enumerated "tag" or "kind" member in the base class that's always set to an indication of the correct type. This might be done for performance reasons, or to permit most-derived types to be trivially copyable. One of the most widely-known examples is in LLVM: https://llvm.org/docs/HowToSetUpLLVMStyleRTTI.html This PR permits pybind11 to be informed of such conventions via a new specializable detail::polymorphic_type_hook<> template, which generalizes the previous logic for determining the runtime type of an object based on C++ RTTI. Implementors provide a way to map from a base class object to a const std::type_info* for the dynamic type; pybind11 then uses this to ensure that casting a Base* to Python creates a Python object that knows it's wrapping the appropriate sort of Derived. There are a number of restrictions with this tag-based static polymorphism support compared to pybind11's existing support for built-in C++ polymorphism: - there is no support for this-pointer adjustment, so only single inheritance is permitted - there is no way to make C++ code call new Python-provided subclasses - when binding C++ classes that redefine a method in a subclass, the .def() must be repeated in the binding for Python to know about the update But these are not much of an issue in practice in many cases, the impact on the complexity of pybind11's innards is minimal and localized, and the support for automatic downcasting improves usability a great deal.
2018-04-14 00:13:10 +00:00
return type_caster_generic::src_and_type(src, cast_type, instance_type);
Fix downcasting of base class pointers When we are returned a base class pointer (either directly or via shared_from_this()) we detect its runtime type (using `typeid`), then end up essentially reinterpret_casting the pointer to the derived type. This is invalid when the base class pointer was a non-first base, and we end up with an invalid pointer. We could dynamic_cast to the most-derived type, but if *that* type isn't pybind11-registered, the resulting pointer given to the base `cast` implementation isn't necessarily valid to be reinterpret_cast'ed back to the backup type. This commit removes the "backup" type argument from the many-argument `cast(...)` and instead does the derived-or-pointer type decision and type lookup in type_caster_base, where the dynamic_cast has to be to correctly get the derived pointer, but also has to do the type lookup to ensure that we don't pass the wrong (derived) pointer when the backup type (i.e. the type caster intrinsic type) pointer is needed. Since the lookup is needed before calling the base cast(), this also changes the input type to a detail::type_info rather than doing a (second) lookup in cast().
2017-04-21 21:14:22 +00:00
}
Fix type caster for heap reference types Need to use the intrinsic type, not the raw type. Fixes #392.
2016-09-07 17:32:49 +00:00
static handle cast(const itype *src, return_value_policy policy, handle parent) {
Fix downcasting of base class pointers When we are returned a base class pointer (either directly or via shared_from_this()) we detect its runtime type (using `typeid`), then end up essentially reinterpret_casting the pointer to the derived type. This is invalid when the base class pointer was a non-first base, and we end up with an invalid pointer. We could dynamic_cast to the most-derived type, but if *that* type isn't pybind11-registered, the resulting pointer given to the base `cast` implementation isn't necessarily valid to be reinterpret_cast'ed back to the backup type. This commit removes the "backup" type argument from the many-argument `cast(...)` and instead does the derived-or-pointer type decision and type lookup in type_caster_base, where the dynamic_cast has to be to correctly get the derived pointer, but also has to do the type lookup to ensure that we don't pass the wrong (derived) pointer when the backup type (i.e. the type caster intrinsic type) pointer is needed. Since the lookup is needed before calling the base cast(), this also changes the input type to a detail::type_info rather than doing a (second) lookup in cast().
2017-04-21 21:14:22 +00:00
auto st = src_and_type(src);
new move value policy
2016-04-25 21:04:27 +00:00
return type_caster_generic::cast(
Fix downcasting of base class pointers When we are returned a base class pointer (either directly or via shared_from_this()) we detect its runtime type (using `typeid`), then end up essentially reinterpret_casting the pointer to the derived type. This is invalid when the base class pointer was a non-first base, and we end up with an invalid pointer. We could dynamic_cast to the most-derived type, but if *that* type isn't pybind11-registered, the resulting pointer given to the base `cast` implementation isn't necessarily valid to be reinterpret_cast'ed back to the backup type. This commit removes the "backup" type argument from the many-argument `cast(...)` and instead does the derived-or-pointer type decision and type lookup in type_caster_base, where the dynamic_cast has to be to correctly get the derived pointer, but also has to do the type lookup to ensure that we don't pass the wrong (derived) pointer when the backup type (i.e. the type caster intrinsic type) pointer is needed. Since the lookup is needed before calling the base cast(), this also changes the input type to a detail::type_info rather than doing a (second) lookup in cast().
2017-04-21 21:14:22 +00:00
st.first, policy, parent, st.second,
copy/move constructor detection workaround (MSVC 2015 bug)
2016-05-01 08:28:00 +00:00
make_copy_constructor(src), make_move_constructor(src));
factored out some common functionality to a non-templated parent class
2015-10-19 21:50:51 +00:00
}
Improve custom holder support (#607) * Abstract away some holder functionality (resolve #585) Custom holder types which don't have `.get()` can select the correct function to call by specializing `holder_traits`. * Add support for move-only holders (fix #605)
2017-01-31 16:05:44 +00:00
static handle cast_holder(const itype *src, const void *holder) {
Fix downcasting of base class pointers When we are returned a base class pointer (either directly or via shared_from_this()) we detect its runtime type (using `typeid`), then end up essentially reinterpret_casting the pointer to the derived type. This is invalid when the base class pointer was a non-first base, and we end up with an invalid pointer. We could dynamic_cast to the most-derived type, but if *that* type isn't pybind11-registered, the resulting pointer given to the base `cast` implementation isn't necessarily valid to be reinterpret_cast'ed back to the backup type. This commit removes the "backup" type argument from the many-argument `cast(...)` and instead does the derived-or-pointer type decision and type lookup in type_caster_base, where the dynamic_cast has to be to correctly get the derived pointer, but also has to do the type lookup to ensure that we don't pass the wrong (derived) pointer when the backup type (i.e. the type caster intrinsic type) pointer is needed. Since the lookup is needed before calling the base cast(), this also changes the input type to a detail::type_info rather than doing a (second) lookup in cast().
2017-04-21 21:14:22 +00:00
auto st = src_and_type(src);
Improve custom holder support (#607) * Abstract away some holder functionality (resolve #585) Custom holder types which don't have `.get()` can select the correct function to call by specializing `holder_traits`. * Add support for move-only holders (fix #605)
2017-01-31 16:05:44 +00:00
return type_caster_generic::cast(
Fix downcasting of base class pointers When we are returned a base class pointer (either directly or via shared_from_this()) we detect its runtime type (using `typeid`), then end up essentially reinterpret_casting the pointer to the derived type. This is invalid when the base class pointer was a non-first base, and we end up with an invalid pointer. We could dynamic_cast to the most-derived type, but if *that* type isn't pybind11-registered, the resulting pointer given to the base `cast` implementation isn't necessarily valid to be reinterpret_cast'ed back to the backup type. This commit removes the "backup" type argument from the many-argument `cast(...)` and instead does the derived-or-pointer type decision and type lookup in type_caster_base, where the dynamic_cast has to be to correctly get the derived pointer, but also has to do the type lookup to ensure that we don't pass the wrong (derived) pointer when the backup type (i.e. the type caster intrinsic type) pointer is needed. Since the lookup is needed before calling the base cast(), this also changes the input type to a detail::type_info rather than doing a (second) lookup in cast().
2017-04-21 21:14:22 +00:00
st.first, return_value_policy::take_ownership, {}, st.second,
Improve custom holder support (#607) * Abstract away some holder functionality (resolve #585) Custom holder types which don't have `.get()` can select the correct function to call by specializing `holder_traits`. * Add support for move-only holders (fix #605)
2017-01-31 16:05:44 +00:00
nullptr, nullptr, holder);
}
Qualify `cast_op_type` to help ICC
2017-10-24 20:59:50 +00:00
template <typename T> using cast_op_type = detail::cast_op_type<T>;
modularized logic in preceding change, fixed issue with char (fixes #150)
2016-03-26 22:04:10 +00:00
Fix type caster for heap reference types Need to use the intrinsic type, not the raw type. Fixes #392.
2016-09-07 17:32:49 +00:00
operator itype*() { return (type *) value; }
operator itype&() { if (!value) throw reference_cast_error(); return *((itype *) value); }
copy/move constructor detection workaround (MSVC 2015 bug)
2016-05-01 08:28:00 +00:00
factored out some common functionality to a non-templated parent class
2015-10-19 21:50:51 +00:00
protected:
Fix linker issue with move constructors on MSVC Fixes the issue as described in the comments of commit e27ea47. This just adds `enable_if_t<std::is_move_constructible<T>::value>` to `make_move_constructor`. The change fixes MSVC and is harmless with other compilers.
2017-06-13 21:47:43 +00:00
using Constructor = void *(*)(const void *);
copy/move constructor detection workaround (MSVC 2015 bug)
2016-05-01 08:28:00 +00:00
/* Only enabled when the types are {copy,move}-constructible *and* when the type
Fix linker issue with move constructors on MSVC Fixes the issue as described in the comments of commit e27ea47. This just adds `enable_if_t<std::is_move_constructible<T>::value>` to `make_move_constructor`. The change fixes MSVC and is harmless with other compilers.
2017-06-13 21:47:43 +00:00
does not have a private operator new implementation. */
template <typename T, typename = enable_if_t<is_copy_constructible<T>::value>>
static auto make_copy_constructor(const T *x) -> decltype(new T(*x), Constructor{}) {
return [](const void *arg) -> void * {
return new T(*reinterpret_cast<const T *>(arg));
};
}
template <typename T, typename = enable_if_t<std::is_move_constructible<T>::value>>
Fix compilation with Intel's compiler ICC was reporting that `try_direct_conversions()` cannot be `constexpr` because `handle` is not a literal type. The fix removes `constexpr` from the function since it isn't strictly needed. This commit also suppresses new false positive warnings which mostly appear in constexpr contexts (where the compiler knows conversions are safe).
2017-07-03 23:27:18 +00:00
static auto make_move_constructor(const T *x) -> decltype(new T(std::move(*const_cast<T *>(x))), Constructor{}) {
Fix linker issue with move constructors on MSVC Fixes the issue as described in the comments of commit e27ea47. This just adds `enable_if_t<std::is_move_constructible<T>::value>` to `make_move_constructor`. The change fixes MSVC and is harmless with other compilers.
2017-06-13 21:47:43 +00:00
return [](const void *arg) -> void * {
return new T(std::move(*const_cast<T *>(reinterpret_cast<const T *>(arg))));
};
}
Fix stl_bind to support movable, non-copyable value types (#490) This commit includes the following changes: * Don't provide make_copy_constructor for non-copyable container make_copy_constructor currently fails for various stl containers (e.g. std::vector, std::unordered_map, std::deque, etc.) when the container's value type (e.g. the "T" or the std::pair<K,T> for a map) is non-copyable. This adds an override that, for types that look like containers, also requires that the value_type be copyable. * stl_bind.h: make bind_{vector,map} work for non-copy-constructible types Most stl_bind modifiers require copying, so if the type isn't copy constructible, we provide a read-only interface instead. In practice, this means that if the type is non-copyable, it will be, for all intents and purposes, read-only from the Python side (but currently it simply fails to compile with such a container). It is still possible for the caller to provide an interface manually (by defining methods on the returned class_ object), but this isn't something stl_bind can handle because the C++ code to construct values is going to be highly dependent on the container value_type. * stl_bind: copy only for arithmetic value types For non-primitive types, we may well be copying some complex type, when returning by reference is more appropriate. This commit returns by internal reference for all but basic arithmetic types. * Return by reference whenever possible Only if we definitely can't--i.e. std::vector<bool>--because v[i] returns something that isn't a T& do we copy; for everything else, we return by reference. For the map case, we can always return by reference (at least for the default stl map/unordered_map).
2016-11-15 11:30:38 +00:00
copy/move constructor detection workaround (MSVC 2015 bug)
2016-05-01 08:28:00 +00:00
static Constructor make_copy_constructor(...) { return nullptr; }
static Constructor make_move_constructor(...) { return nullptr; }
factored out some common functionality to a non-templated parent class
2015-10-19 21:50:51 +00:00
};
opaque type redesign
2016-04-28 14:25:24 +00:00
template <typename type, typename SFINAE = void> class type_caster : public type_caster_base<type> { };
Support keyword arguments and generalized unpacking in C++ A Python function can be called with the syntax: ```python foo(a1, a2, *args, ka=1, kb=2, **kwargs) ``` This commit adds support for the equivalent syntax in C++: ```c++ foo(a1, a2, *args, "ka"_a=1, "kb"_a=2, **kwargs) ``` In addition, generalized unpacking is implemented, as per PEP 448, which allows calls with multiple * and ** unpacking: ```python bar(*args1, 99, *args2, 101, **kwargs1, kz=200, **kwargs2) ``` and ```c++ bar(*args1, 99, *args2, 101, **kwargs1, "kz"_a=200, **kwargs2) ```
2016-08-29 01:05:42 +00:00
template <typename type> using make_caster = type_caster<intrinsic_t<type>>;
opaque type redesign
2016-04-28 14:25:24 +00:00
Clean up cast operator invocations (#531) This adds a `detail::cast_op<T>(caster)` function which handles the rather verbose: caster.operator typename CasterType::template cast_op_type<T>() which allows various places to use the shorter and clearer: cast_op<T>(caster) instead of the full verbose cast operator invocation.
2016-11-25 17:35:00 +00:00
// Shortcut for calling a caster's `cast_op_type` cast operator for casting a type_caster to a T
Simplify cast_op return type (#532) Using a complicated declval here was pointlessly complicated: we already know the type, because that's what cast_op_type<T> is in the first place. (The declval also broke MSVC).
2016-11-25 18:23:01 +00:00
template <typename T> typename make_caster<T>::template cast_op_type<T> cast_op(make_caster<T> &caster) {
Clean up cast operator invocations (#531) This adds a `detail::cast_op<T>(caster)` function which handles the rather verbose: caster.operator typename CasterType::template cast_op_type<T>() which allows various places to use the shorter and clearer: cast_op<T>(caster) instead of the full verbose cast operator invocation.
2016-11-25 17:35:00 +00:00
return caster.operator typename make_caster<T>::template cast_op_type<T>();
}
Add movable cast support to type casters This commit allows type_casters to allow their local values to be moved away, rather than copied, when the type caster instance itself is an rvalue. This only applies (automatically) to type casters using PYBIND11_TYPE_CASTER; the generic type type casters don't own their own pointer, and various value casters (e.g. std::string, std::pair, arithmetic types) already cast to an rvalue (i.e. they return by value). This updates various calling code to attempt to get a movable value whenever the value is itself coming from a type caster about to be destroyed: for example, when constructing an std::pair or various stl.h containers. For types that don't support value moving, the cast_op falls back to an lvalue cast. There wasn't an obvious place to add the tests, so I added them to test_copy_move_policies, but also renamed it to drop the _policies as it now tests more than just policies.
2017-05-14 19:57:26 +00:00
template <typename T> typename make_caster<T>::template cast_op_type<typename std::add_rvalue_reference<T>::type>
cast_op(make_caster<T> &&caster) {
return std::move(caster).operator
typename make_caster<T>::template cast_op_type<typename std::add_rvalue_reference<T>::type>();
Clean up cast operator invocations (#531) This adds a `detail::cast_op<T>(caster)` function which handles the rather verbose: caster.operator typename CasterType::template cast_op_type<T>() which allows various places to use the shorter and clearer: cast_op<T>(caster) instead of the full verbose cast operator invocation.
2016-11-25 17:35:00 +00:00
}
std::reference_wrapper: non-generic types; no None This reimplements the std::reference_wrapper<T> caster to be a shell around the underlying T caster (rather than assuming T is a generic type), which lets it work for things like `std::reference_wrapper<int>` or anything else custom type caster with a lvalue cast operator. This also makes it properly fail when None is provided, just as an ordinary lvalue reference argument would similarly fail. This also adds a static assert to test that T has an appropriate type caster. It triggers for casters like `std::pair`, which have return-by-value cast operators. (In theory this could be supported by storing a local temporary for such types, but that's beyond the scope of this PR). This also replaces `automatic` or `take_ownership` return value policies with `automatic_reference` as taking ownership of a reference inside a reference_wrapper is not valid.
2017-05-12 17:40:05 +00:00
template <typename type> class type_caster<std::reference_wrapper<type>> {
private:
using caster_t = make_caster<type>;
caster_t subcaster;
using subcaster_cast_op_type = typename caster_t::template cast_op_type<type>;
static_assert(std::is_same<typename std::remove_const<type>::type &, subcaster_cast_op_type>::value,
"std::reference_wrapper<T> caster requires T to have a caster with an `T &` operator");
added caster for std::reference_wrapper (fixes #171)
2016-04-20 15:00:57 +00:00
public:
std::reference_wrapper: non-generic types; no None This reimplements the std::reference_wrapper<T> caster to be a shell around the underlying T caster (rather than assuming T is a generic type), which lets it work for things like `std::reference_wrapper<int>` or anything else custom type caster with a lvalue cast operator. This also makes it properly fail when None is provided, just as an ordinary lvalue reference argument would similarly fail. This also adds a static assert to test that T has an appropriate type caster. It triggers for casters like `std::pair`, which have return-by-value cast operators. (In theory this could be supported by storing a local temporary for such types, but that's beyond the scope of this PR). This also replaces `automatic` or `take_ownership` return value policies with `automatic_reference` as taking ownership of a reference inside a reference_wrapper is not valid.
2017-05-12 17:40:05 +00:00
bool load(handle src, bool convert) { return subcaster.load(src, convert); }
Make it possible to generate constexpr signatures in C++11 mode The current C++14 constexpr signatures don't require relaxed constexpr, but only `auto` return type deduction. To get around this in C++11, the type caster's `name()` static member functions are turned into `static constexpr auto` variables.
2017-07-02 09:48:56 +00:00
static constexpr auto name = caster_t::name;
added caster for std::reference_wrapper (fixes #171)
2016-04-20 15:00:57 +00:00
static handle cast(const std::reference_wrapper<type> &src, return_value_policy policy, handle parent) {
std::reference_wrapper: non-generic types; no None This reimplements the std::reference_wrapper<T> caster to be a shell around the underlying T caster (rather than assuming T is a generic type), which lets it work for things like `std::reference_wrapper<int>` or anything else custom type caster with a lvalue cast operator. This also makes it properly fail when None is provided, just as an ordinary lvalue reference argument would similarly fail. This also adds a static assert to test that T has an appropriate type caster. It triggers for casters like `std::pair`, which have return-by-value cast operators. (In theory this could be supported by storing a local temporary for such types, but that's beyond the scope of this PR). This also replaces `automatic` or `take_ownership` return value policies with `automatic_reference` as taking ownership of a reference inside a reference_wrapper is not valid.
2017-05-12 17:40:05 +00:00
// It is definitely wrong to take ownership of this pointer, so mask that rvp
if (policy == return_value_policy::take_ownership || policy == return_value_policy::automatic)
policy = return_value_policy::automatic_reference;
return caster_t::cast(&src.get(), policy, parent);
added caster for std::reference_wrapper (fixes #171)
2016-04-20 15:00:57 +00:00
}
completed implicit type casters for reference_wrapper
2016-04-21 10:21:14 +00:00
template <typename T> using cast_op_type = std::reference_wrapper<type>;
std::reference_wrapper: non-generic types; no None This reimplements the std::reference_wrapper<T> caster to be a shell around the underlying T caster (rather than assuming T is a generic type), which lets it work for things like `std::reference_wrapper<int>` or anything else custom type caster with a lvalue cast operator. This also makes it properly fail when None is provided, just as an ordinary lvalue reference argument would similarly fail. This also adds a static assert to test that T has an appropriate type caster. It triggers for casters like `std::pair`, which have return-by-value cast operators. (In theory this could be supported by storing a local temporary for such types, but that's beyond the scope of this PR). This also replaces `automatic` or `take_ownership` return value policies with `automatic_reference` as taking ownership of a reference inside a reference_wrapper is not valid.
2017-05-12 17:40:05 +00:00
operator std::reference_wrapper<type>() { return subcaster.operator subcaster_cast_op_type&(); }
added caster for std::reference_wrapper (fixes #171)
2016-04-20 15:00:57 +00:00
};
consistent macro naming throughout the project
2015-10-18 14:48:30 +00:00
#define PYBIND11_TYPE_CASTER(type, py_name) \
Initial commit
2015-07-05 18:05:44 +00:00
protected: \
type value; \
public: \
Simplify function signature annotation and parsing `type_descr` is now applied only to the final signature so that it only marks the argument types, but not nested types (e.g. for tuples) or return types.
2017-08-31 12:38:23 +00:00
static constexpr auto name = py_name; \
Fix regression: container pointers not castable PR #936 broke the ability to return a pointer to a stl container (and, likewise, to a tuple) because the added deduced type matched a non-const pointer argument: the pointer-accepting `cast` in PYBIND11_TYPE_CASTER had a `const type *`, which is a worse match for a non-const pointer than the universal reference template #936 added. This changes the provided TYPE_CASTER cast(ptr) to take the pointer by template arg (so that it will accept either const or non-const pointer). It has two other effects: it slightly reduces .so size (because many type casters never actually need the pointer cast at all), and it allows type casters to provide their untemplated pointer `cast()` that will take precedence over the templated version provided in the macro.
2017-07-07 00:41:52 +00:00
template <typename T_, enable_if_t<std::is_same<type, remove_cv_t<T_>>::value, int> = 0> \
static handle cast(T_ *src, return_value_policy policy, handle parent) { \
Fix nullptr to None conversion for builtin type casters Fixes #731. Generally, this applies to any caster made with PYBIND11_TYPE_CASTER().
2017-03-15 12:57:10 +00:00
if (!src) return none().release(); \
Support `take_ownership` for custom type casters given a pointer This changes the pointer `cast()` in `PYBIND11_TYPE_CASTER` to recognize the `take_ownership` policy: if casting a pointer with take-ownership, the `cast()` now recalls `cast()` with a dereferenced rvalue (rather than the previous code, which was always calling it with a const lvalue reference), and deletes the pointer after the chained `cast()` is complete. This makes code like: m.def("f", []() { return new std::vector<int>(100, 1); }, py::return_value_policy::take_ownership); do the expected thing by taking over ownership of the returned pointer (which is deleted once the chained cast completes).
2017-07-07 21:26:14 +00:00
if (policy == return_value_policy::take_ownership) { \
auto h = cast(std::move(*src), policy, parent); delete src; return h; \
} else { \
return cast(*src, policy, parent); \
} \
Initial commit
2015-07-05 18:05:44 +00:00
} \
operator type*() { return &value; } \
modularized logic in preceding change, fixed issue with char (fixes #150)
2016-03-26 22:04:10 +00:00
operator type&() { return value; } \
Add movable cast support to type casters This commit allows type_casters to allow their local values to be moved away, rather than copied, when the type caster instance itself is an rvalue. This only applies (automatically) to type casters using PYBIND11_TYPE_CASTER; the generic type type casters don't own their own pointer, and various value casters (e.g. std::string, std::pair, arithmetic types) already cast to an rvalue (i.e. they return by value). This updates various calling code to attempt to get a movable value whenever the value is itself coming from a type caster about to be destroyed: for example, when constructing an std::pair or various stl.h containers. For types that don't support value moving, the cast_op falls back to an lvalue cast. There wasn't an obvious place to add the tests, so I added them to test_copy_move_policies, but also renamed it to drop the _policies as it now tests more than just policies.
2017-05-14 19:57:26 +00:00
operator type&&() && { return std::move(value); } \
Fix regression: container pointers not castable PR #936 broke the ability to return a pointer to a stl container (and, likewise, to a tuple) because the added deduced type matched a non-const pointer argument: the pointer-accepting `cast` in PYBIND11_TYPE_CASTER had a `const type *`, which is a worse match for a non-const pointer than the universal reference template #936 added. This changes the provided TYPE_CASTER cast(ptr) to take the pointer by template arg (so that it will accept either const or non-const pointer). It has two other effects: it slightly reduces .so size (because many type casters never actually need the pointer cast at all), and it allows type casters to provide their untemplated pointer `cast()` that will take precedence over the templated version provided in the macro.
2017-07-07 00:41:52 +00:00
template <typename T_> using cast_op_type = pybind11::detail::movable_cast_op_type<T_>
Initial commit
2015-07-05 18:05:44 +00:00
considerable simplifications to the Python type casters
2015-12-16 11:11:01 +00:00
Unicode fixes and docs (#624) * Propagate unicode conversion failure If returning a std::string with invalid utf-8 data, we currently fail with an uninformative TypeError instead of propagating the UnicodeDecodeError that Python sets on failure. * Add support for u16/u32strings and literals This adds support for wchar{16,32}_t character literals and the associated std::u{16,32}string types. It also folds the character/string conversion into a single type_caster template, since the type casters for string and wstring were mostly the same anyway. * Added too-long and too-big character conversion errors With this commit, when casting to a single character, as opposed to a C-style string, we make sure the input wasn't a multi-character string or a single character with codepoint too large for the character type. This also changes the character cast op to CharT instead of CharT& (we need to be able to return a temporary decoded char value, but also because there's little gained by bothering with an lvalue return here). Finally it changes the char caster to 'has-a-string-caster' instead of 'is-a-string-caster' because, with the cast_op change above, there's nothing at all gained from inheritance. This also lets us remove the `success` from the string caster (which was only there for the char caster) into the char caster itself. (I also renamed it to 'none' and inverted its value to better reflect its purpose). The None -> nullptr loading also now takes place only under a `convert = true` load pass. Although it's unlikely that a function taking a char also has overloads that can take a None, it seems marginally more correct to treat it as a conversion. This commit simplifies the size assumptions about character sizes with static_asserts to back them up.
2017-02-14 10:08:19 +00:00
template <typename CharT> using is_std_char_type = any_of<
std::is_same<CharT, char>, /* std::string */
std::is_same<CharT, char16_t>, /* std::u16string */
std::is_same<CharT, char32_t>, /* std::u32string */
std::is_same<CharT, wchar_t> /* std::wstring */
>;
generic integer type handling
2015-11-30 11:30:28 +00:00
template <typename T>
Unicode fixes and docs (#624) * Propagate unicode conversion failure If returning a std::string with invalid utf-8 data, we currently fail with an uninformative TypeError instead of propagating the UnicodeDecodeError that Python sets on failure. * Add support for u16/u32strings and literals This adds support for wchar{16,32}_t character literals and the associated std::u{16,32}string types. It also folds the character/string conversion into a single type_caster template, since the type casters for string and wstring were mostly the same anyway. * Added too-long and too-big character conversion errors With this commit, when casting to a single character, as opposed to a C-style string, we make sure the input wasn't a multi-character string or a single character with codepoint too large for the character type. This also changes the character cast op to CharT instead of CharT& (we need to be able to return a temporary decoded char value, but also because there's little gained by bothering with an lvalue return here). Finally it changes the char caster to 'has-a-string-caster' instead of 'is-a-string-caster' because, with the cast_op change above, there's nothing at all gained from inheritance. This also lets us remove the `success` from the string caster (which was only there for the char caster) into the char caster itself. (I also renamed it to 'none' and inverted its value to better reflect its purpose). The None -> nullptr loading also now takes place only under a `convert = true` load pass. Although it's unlikely that a function taking a char also has overloads that can take a None, it seems marginally more correct to treat it as a conversion. This commit simplifies the size assumptions about character sizes with static_asserts to back them up.
2017-02-14 10:08:19 +00:00
struct type_caster<T, enable_if_t<std::is_arithmetic<T>::value && !is_std_char_type<T>::value>> {
Made arithmetic and complex casters respect `convert` Arithmetic and complex casters now only do a converting cast when `convert=true`; previously they would convert always (e.g. when passing an int to a float-accepting function, or a float to complex-accepting function).
2017-02-04 01:16:14 +00:00
using _py_type_0 = conditional_t<sizeof(T) <= sizeof(long), long, long long>;
using _py_type_1 = conditional_t<std::is_signed<T>::value, _py_type_0, typename std::make_unsigned<_py_type_0>::type>;
using py_type = conditional_t<std::is_floating_point<T>::value, double, _py_type_1>;
generic integer type handling
2015-11-30 11:30:28 +00:00
public:
Initial commit
2015-07-05 18:05:44 +00:00
Made arithmetic and complex casters respect `convert` Arithmetic and complex casters now only do a converting cast when `convert=true`; previously they would convert always (e.g. when passing an int to a float-accepting function, or a float to complex-accepting function).
2017-02-04 01:16:14 +00:00
bool load(handle src, bool convert) {
generic integer type handling
2015-11-30 11:30:28 +00:00
py_type py_value;
Initial commit
2015-07-05 18:05:44 +00:00
Made arithmetic and complex casters respect `convert` Arithmetic and complex casters now only do a converting cast when `convert=true`; previously they would convert always (e.g. when passing an int to a float-accepting function, or a float to complex-accepting function).
2017-02-04 01:16:14 +00:00
if (!src)
nicer type_caster::load() calling conventions
2016-05-10 14:59:01 +00:00
return false;
Made arithmetic and complex casters respect `convert` Arithmetic and complex casters now only do a converting cast when `convert=true`; previously they would convert always (e.g. when passing an int to a float-accepting function, or a float to complex-accepting function).
2017-02-04 01:16:14 +00:00
if (std::is_floating_point<T>::value) {
if (convert || PyFloat_Check(src.ptr()))
py_value = (py_type) PyFloat_AsDouble(src.ptr());
else
return false;
Fix unsigned error value casting When casting to an unsigned type from a python 2 `int`, we currently cast using `(unsigned long long) PyLong_AsUnsignedLong(src.ptr())`. If the Python cast fails, it returns (unsigned long) -1, but then we cast this to `unsigned long long`, which means we get 4294967295, but because that isn't equal to `(unsigned long long) -1`, we don't detect the failure. This commit moves the unsigned casting into a `detail::as_unsigned` function which, upon error, casts -1 to the final type, and otherwise casts the return value to the final type to avoid the problematic double cast when an error occurs. The error most commonly shows up wherever `long` is 32-bits (e.g. under both 32- and 64-bit Windows, and under 32-bit linux) when passing a negative value to a bound function taking an `unsigned long`. Fixes #929. The added tests also trigger a latent segfault under PyPy: when casting to an integer smaller than `long` (e.g. casting to a `uint32_t` on a 64-bit `long` architecture) we check both for a Python error and also that the resulting intermediate value will fit in the final type. If there is no conversion error, but we get a value that would overflow, we end up calling `PyErr_ExceptionMatches()` illegally: that call is only allowed when there is a current exception. Under PyPy, this segfaults the test suite. It doesn't appear to segfault under CPython, but the documentation suggests that it *could* do so. The fix is to only check for the exception match if we actually got an error.
2017-07-01 20:31:49 +00:00
} else if (PyFloat_Check(src.ptr())) {
return false;
} else if (std::is_unsigned<py_type>::value) {
py_value = as_unsigned<py_type>(src.ptr());
} else { // signed integer:
py_value = sizeof(T) <= sizeof(long)
? (py_type) PyLong_AsLong(src.ptr())
: (py_type) PYBIND11_LONG_AS_LONGLONG(src.ptr());
generic integer type handling
2015-11-30 11:30:28 +00:00
}
Fix unsigned error value casting When casting to an unsigned type from a python 2 `int`, we currently cast using `(unsigned long long) PyLong_AsUnsignedLong(src.ptr())`. If the Python cast fails, it returns (unsigned long) -1, but then we cast this to `unsigned long long`, which means we get 4294967295, but because that isn't equal to `(unsigned long long) -1`, we don't detect the failure. This commit moves the unsigned casting into a `detail::as_unsigned` function which, upon error, casts -1 to the final type, and otherwise casts the return value to the final type to avoid the problematic double cast when an error occurs. The error most commonly shows up wherever `long` is 32-bits (e.g. under both 32- and 64-bit Windows, and under 32-bit linux) when passing a negative value to a bound function taking an `unsigned long`. Fixes #929. The added tests also trigger a latent segfault under PyPy: when casting to an integer smaller than `long` (e.g. casting to a `uint32_t` on a 64-bit `long` architecture) we check both for a Python error and also that the resulting intermediate value will fit in the final type. If there is no conversion error, but we get a value that would overflow, we end up calling `PyErr_ExceptionMatches()` illegally: that call is only allowed when there is a current exception. Under PyPy, this segfaults the test suite. It doesn't appear to segfault under CPython, but the documentation suggests that it *could* do so. The fix is to only check for the exception match if we actually got an error.
2017-07-01 20:31:49 +00:00
bool py_err = py_value == (py_type) -1 && PyErr_Occurred();
if (py_err || (std::is_integral<T>::value && sizeof(py_type) != sizeof(T) &&
(py_value < (py_type) std::numeric_limits<T>::min() ||
py_value > (py_type) std::numeric_limits<T>::max()))) {
bool type_error = py_err && PyErr_ExceptionMatches(
enum_: fix implicit conversion on Python 2.7 Enumerations on Python 2.7 were not always implicitly converted to integers (depending on the target size). This patch adds a __long__ conversion function (only enabled on 2.7) which fixes this issue. The attached test case fails without this patch.
2017-04-28 12:46:52 +00:00
#if PY_VERSION_HEX < 0x03000000 && !defined(PYPY_VERSION)
Fix unsigned error value casting When casting to an unsigned type from a python 2 `int`, we currently cast using `(unsigned long long) PyLong_AsUnsignedLong(src.ptr())`. If the Python cast fails, it returns (unsigned long) -1, but then we cast this to `unsigned long long`, which means we get 4294967295, but because that isn't equal to `(unsigned long long) -1`, we don't detect the failure. This commit moves the unsigned casting into a `detail::as_unsigned` function which, upon error, casts -1 to the final type, and otherwise casts the return value to the final type to avoid the problematic double cast when an error occurs. The error most commonly shows up wherever `long` is 32-bits (e.g. under both 32- and 64-bit Windows, and under 32-bit linux) when passing a negative value to a bound function taking an `unsigned long`. Fixes #929. The added tests also trigger a latent segfault under PyPy: when casting to an integer smaller than `long` (e.g. casting to a `uint32_t` on a 64-bit `long` architecture) we check both for a Python error and also that the resulting intermediate value will fit in the final type. If there is no conversion error, but we get a value that would overflow, we end up calling `PyErr_ExceptionMatches()` illegally: that call is only allowed when there is a current exception. Under PyPy, this segfaults the test suite. It doesn't appear to segfault under CPython, but the documentation suggests that it *could* do so. The fix is to only check for the exception match if we actually got an error.
2017-07-01 20:31:49 +00:00
PyExc_SystemError
pybind11: implicitly convert NumPy integer scalars The current integer caster was unnecessarily strict and rejected various kinds of NumPy integer types when calling C++ functions expecting normal integers. This relaxes the current behavior.
2016-10-27 22:37:07 +00:00
#else
Fix unsigned error value casting When casting to an unsigned type from a python 2 `int`, we currently cast using `(unsigned long long) PyLong_AsUnsignedLong(src.ptr())`. If the Python cast fails, it returns (unsigned long) -1, but then we cast this to `unsigned long long`, which means we get 4294967295, but because that isn't equal to `(unsigned long long) -1`, we don't detect the failure. This commit moves the unsigned casting into a `detail::as_unsigned` function which, upon error, casts -1 to the final type, and otherwise casts the return value to the final type to avoid the problematic double cast when an error occurs. The error most commonly shows up wherever `long` is 32-bits (e.g. under both 32- and 64-bit Windows, and under 32-bit linux) when passing a negative value to a bound function taking an `unsigned long`. Fixes #929. The added tests also trigger a latent segfault under PyPy: when casting to an integer smaller than `long` (e.g. casting to a `uint32_t` on a 64-bit `long` architecture) we check both for a Python error and also that the resulting intermediate value will fit in the final type. If there is no conversion error, but we get a value that would overflow, we end up calling `PyErr_ExceptionMatches()` illegally: that call is only allowed when there is a current exception. Under PyPy, this segfaults the test suite. It doesn't appear to segfault under CPython, but the documentation suggests that it *could* do so. The fix is to only check for the exception match if we actually got an error.
2017-07-01 20:31:49 +00:00
PyExc_TypeError
pybind11: implicitly convert NumPy integer scalars The current integer caster was unnecessarily strict and rejected various kinds of NumPy integer types when calling C++ functions expecting normal integers. This relaxes the current behavior.
2016-10-27 22:37:07 +00:00
#endif
Fix unsigned error value casting When casting to an unsigned type from a python 2 `int`, we currently cast using `(unsigned long long) PyLong_AsUnsignedLong(src.ptr())`. If the Python cast fails, it returns (unsigned long) -1, but then we cast this to `unsigned long long`, which means we get 4294967295, but because that isn't equal to `(unsigned long long) -1`, we don't detect the failure. This commit moves the unsigned casting into a `detail::as_unsigned` function which, upon error, casts -1 to the final type, and otherwise casts the return value to the final type to avoid the problematic double cast when an error occurs. The error most commonly shows up wherever `long` is 32-bits (e.g. under both 32- and 64-bit Windows, and under 32-bit linux) when passing a negative value to a bound function taking an `unsigned long`. Fixes #929. The added tests also trigger a latent segfault under PyPy: when casting to an integer smaller than `long` (e.g. casting to a `uint32_t` on a 64-bit `long` architecture) we check both for a Python error and also that the resulting intermediate value will fit in the final type. If there is no conversion error, but we get a value that would overflow, we end up calling `PyErr_ExceptionMatches()` illegally: that call is only allowed when there is a current exception. Under PyPy, this segfaults the test suite. It doesn't appear to segfault under CPython, but the documentation suggests that it *could* do so. The fix is to only check for the exception match if we actually got an error.
2017-07-01 20:31:49 +00:00
);
generic integer type handling
2015-11-30 11:30:28 +00:00
PyErr_Clear();
Made arithmetic and complex casters respect `convert` Arithmetic and complex casters now only do a converting cast when `convert=true`; previously they would convert always (e.g. when passing an int to a float-accepting function, or a float to complex-accepting function).
2017-02-04 01:16:14 +00:00
if (type_error && convert && PyNumber_Check(src.ptr())) {
Fix a reference leak in the number converter (#1078) Fixes #1075. `PyNumber_Float()` and `PyNumber_Long()` return new references.
2017-09-10 14:53:02 +00:00
auto tmp = reinterpret_steal<object>(std::is_floating_point<T>::value
? PyNumber_Float(src.ptr())
: PyNumber_Long(src.ptr()));
address number caster regression (fixes #484)
2016-11-07 14:59:01 +00:00
PyErr_Clear();
return load(tmp, false);
}
generic integer type handling
2015-11-30 11:30:28 +00:00
return false;
}
Initial commit
2015-07-05 18:05:44 +00:00
generic integer type handling
2015-11-30 11:30:28 +00:00
value = (T) py_value;
return true;
}
Untangle cast logic to not implicitly require castability (#1442) The current code requires implicitly that integral types are cast-able to floating point. In case of strongly-typed integrals (e.g. as explained at http://www.ilikebigbits.com/blog/2014/5/6/type-safe-identifiers-in-c) this is not always the case. This commit uses SFINAE to move the numeric conversions into separate `cast()` implementations to avoid the issue.
2018-07-17 13:48:51 +00:00
template<typename U = T>
static typename std::enable_if<std::is_floating_point<U>::value, handle>::type
cast(U src, return_value_policy /* policy */, handle /* parent */) {
return PyFloat_FromDouble((double) src);
}
template<typename U = T>
static typename std::enable_if<!std::is_floating_point<U>::value && std::is_signed<U>::value && (sizeof(U) <= sizeof(long)), handle>::type
cast(U src, return_value_policy /* policy */, handle /* parent */) {
return PYBIND11_LONG_FROM_SIGNED((long) src);
}
template<typename U = T>
static typename std::enable_if<!std::is_floating_point<U>::value && std::is_unsigned<U>::value && (sizeof(U) <= sizeof(unsigned long)), handle>::type
cast(U src, return_value_policy /* policy */, handle /* parent */) {
return PYBIND11_LONG_FROM_UNSIGNED((unsigned long) src);
}
template<typename U = T>
static typename std::enable_if<!std::is_floating_point<U>::value && std::is_signed<U>::value && (sizeof(U) > sizeof(long)), handle>::type
cast(U src, return_value_policy /* policy */, handle /* parent */) {
return PyLong_FromLongLong((long long) src);
}
template<typename U = T>
static typename std::enable_if<!std::is_floating_point<U>::value && std::is_unsigned<U>::value && (sizeof(U) > sizeof(unsigned long)), handle>::type
cast(U src, return_value_policy /* policy */, handle /* parent */) {
return PyLong_FromUnsignedLongLong((unsigned long long) src);
generic integer type handling
2015-11-30 11:30:28 +00:00
}
Add _<bool>("s1", "s2") ternary & use TYPE_CASTER This commit adds an additional _ template function for compile-time selection between two description strings. This in turn allows the elimination of needing two name() methods in type_caster<arithmetic types> and type_caster<eigen types>, which allows them to start using PYBIND11_TYPE_CASTER instead, simplifying their code by eliminating all the code that they are duplicating from the macro.
2016-07-06 04:40:54 +00:00
PYBIND11_TYPE_CASTER(T, _<std::is_integral<T>::value>("int", "float"));
generic integer type handling
2015-11-30 11:30:28 +00:00
};
Initial commit
2015-07-05 18:05:44 +00:00
Add type casters for nullopt_t, fix none refcount (#499) * Incref returned None in std::optional type caster * Add type casters for nullopt_t * Add a test for nullopt_t
2016-11-15 12:00:38 +00:00
template<typename T> struct void_caster {
Initial commit
2015-07-05 18:05:44 +00:00
public:
Fix std::nullptr_t caster (#840) * Fix compilation error with std::nullptr_t * Enable conversion from None to std::nullptr_t and std::nullopt_t Fixes #839.
2017-05-09 21:30:05 +00:00
bool load(handle src, bool) {
if (src && src.is_none())
return true;
return false;
}
Add type casters for nullopt_t, fix none refcount (#499) * Incref returned None in std::optional type caster * Add type casters for nullopt_t * Add a test for nullopt_t
2016-11-15 12:00:38 +00:00
static handle cast(T, return_value_policy /* policy */, handle /* parent */) {
fixed Py_None reference couting
2016-09-08 13:53:18 +00:00
return none().inc_ref();
Initial commit
2015-07-05 18:05:44 +00:00
}
Add type casters for nullopt_t, fix none refcount (#499) * Incref returned None in std::optional type caster * Add type casters for nullopt_t * Add a test for nullopt_t
2016-11-15 12:00:38 +00:00
PYBIND11_TYPE_CASTER(T, _("None"));
Initial commit
2015-07-05 18:05:44 +00:00
};
Add type casters for nullopt_t, fix none refcount (#499) * Incref returned None in std::optional type caster * Add type casters for nullopt_t * Add a test for nullopt_t
2016-11-15 12:00:38 +00:00
template <> class type_caster<void_type> : public void_caster<void_type> {};
added feature to pass void* pointers by popular demand
2016-03-26 16:51:09 +00:00
template <> class type_caster<void> : public type_caster<void_type> {
public:
using type_caster<void_type>::cast;
bool load(handle h, bool) {
nicer type_caster::load() calling conventions
2016-05-10 14:59:01 +00:00
if (!h) {
return false;
Use handle::is_none() instead of raw ptrs
2016-08-29 01:38:47 +00:00
} else if (h.is_none()) {
allow nullptr when passing void* values
2016-03-26 19:41:28 +00:00
value = nullptr;
return true;
}
enable passing C++ instances to void*-valued arguments
2016-04-30 17:56:10 +00:00
/* Check if this is a capsule */
Add py::isinstance<T>(obj) for generalized Python type checking Allows checking the Python types before creating an object instead of after. For example: ```c++ auto l = list(ptr, true); if (l.check()) // ... ``` The above is replaced with: ```c++ if (isinstance<list>(ptr)) { auto l = reinterpret_borrow(ptr); // ... } ``` This deprecates `py::object::check()`. `py::isinstance()` covers the same use case, but it can also check for user-defined types: ```c++ class Pet { ... }; py::class_<Pet>(...); m.def("is_pet", [](py::object obj) { return py::isinstance<Pet>(obj); // works as expected }); ```
2016-10-23 12:50:08 +00:00
if (isinstance<capsule>(h)) {
Add py::reinterpret_borrow<T>()/steal<T>() for low-level unchecked casts The pytype converting constructors are convenient and safe for user code, but for library internals the additional type checks and possible conversions are sometimes not desired. `reinterpret_borrow<T>()` and `reinterpret_steal<T>()` serve as the low-level unsafe counterparts of `cast<T>()`. This deprecates the `object(handle, bool)` constructor. Renamed `borrowed` parameter to `is_borrowed` to avoid shadowing warnings on MSVC.
2016-10-28 01:08:15 +00:00
value = reinterpret_borrow<capsule>(h);
enable passing C++ instances to void*-valued arguments
2016-04-30 17:56:10 +00:00
return true;
}
/* Check if this is a C++ type */
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
auto &bases = all_type_info((PyTypeObject *) h.get_type().ptr());
if (bases.size() == 1) { // Only allowing loading from a single-value type
value = values_and_holders(reinterpret_cast<instance *>(h.ptr())).begin()->value_ptr();
enable passing C++ instances to void*-valued arguments
2016-04-30 17:56:10 +00:00
return true;
}
/* Fail */
return false;
added feature to pass void* pointers by popular demand
2016-03-26 16:51:09 +00:00
}
enabled casting of const void*
2016-04-30 17:13:18 +00:00
static handle cast(const void *ptr, return_value_policy /* policy */, handle /* parent */) {
allow nullptr when passing void* values
2016-03-26 19:41:28 +00:00
if (ptr)
return capsule(ptr).release();
else
fixed Py_None reference couting
2016-09-08 13:53:18 +00:00
return none().inc_ref();
added feature to pass void* pointers by popular demand
2016-03-26 16:51:09 +00:00
}
allow nullptr when passing void* values
2016-03-26 19:41:28 +00:00
another corner case (fixes #151)
2016-03-26 23:19:32 +00:00
template <typename T> using cast_op_type = void*&;
operator void *&() { return value; }
Simplify function signature annotation and parsing `type_descr` is now applied only to the final signature so that it only marks the argument types, but not nested types (e.g. for tuples) or return types.
2017-08-31 12:38:23 +00:00
static constexpr auto name = _("capsule");
added feature to pass void* pointers by popular demand
2016-03-26 16:51:09 +00:00
private:
modularized logic in preceding change, fixed issue with char (fixes #150)
2016-03-26 22:04:10 +00:00
void *value = nullptr;
added feature to pass void* pointers by popular demand
2016-03-26 16:51:09 +00:00
};
Fix std::nullptr_t caster (#840) * Fix compilation error with std::nullptr_t * Enable conversion from None to std::nullptr_t and std::nullopt_t Fixes #839.
2017-05-09 21:30:05 +00:00
template <> class type_caster<std::nullptr_t> : public void_caster<std::nullptr_t> { };
don't throw an exception when python deallocates an object which still exists on the C++ side
2015-10-01 16:37:26 +00:00
Initial commit
2015-07-05 18:05:44 +00:00
template <> class type_caster<bool> {
public:
Implicit conversions to bool + np.bool_ conversion (#925) This adds support for implicit conversions to bool from Python types with `__bool__` (Python 3) or `__nonzero__` (Python 2) attributes, and adds direct (i.e. non-converting) support for numpy bools.
2017-07-23 15:02:43 +00:00
bool load(handle src, bool convert) {
nicer type_caster::load() calling conventions
2016-05-10 14:59:01 +00:00
if (!src) return false;
else if (src.ptr() == Py_True) { value = true; return true; }
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
else if (src.ptr() == Py_False) { value = false; return true; }
Implicit conversions to bool + np.bool_ conversion (#925) This adds support for implicit conversions to bool from Python types with `__bool__` (Python 3) or `__nonzero__` (Python 2) attributes, and adds direct (i.e. non-converting) support for numpy bools.
2017-07-23 15:02:43 +00:00
else if (convert || !strcmp("numpy.bool_", Py_TYPE(src.ptr())->tp_name)) {
// (allow non-implicit conversion for numpy booleans)
Py_ssize_t res = -1;
if (src.is_none()) {
res = 0; // None is implicitly converted to False
}
#if defined(PYPY_VERSION)
// On PyPy, check that "__bool__" (or "__nonzero__" on Python 2.7) attr exists
else if (hasattr(src, PYBIND11_BOOL_ATTR)) {
res = PyObject_IsTrue(src.ptr());
}
#else
// Alternate approach for CPython: this does the same as the above, but optimized
// using the CPython API so as to avoid an unneeded attribute lookup.
else if (auto tp_as_number = src.ptr()->ob_type->tp_as_number) {
if (PYBIND11_NB_BOOL(tp_as_number)) {
res = (*PYBIND11_NB_BOOL(tp_as_number))(src.ptr());
}
}
#endif
if (res == 0 || res == 1) {
value = (bool) res;
return true;
}
}
return false;
Initial commit
2015-07-05 18:05:44 +00:00
}
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
static handle cast(bool src, return_value_policy /* policy */, handle /* parent */) {
return handle(src ? Py_True : Py_False).inc_ref();
Initial commit
2015-07-05 18:05:44 +00:00
}
Much more efficient generation of function signatures, updated docs This modification taps into some newer C++14 features (if present) to generate function signatures considerably more efficiently at compile time rather than at run time. With this change, pybind11 binaries are now *2.1 times* smaller compared to the Boost.Python baseline in the benchmark. Compilation times get a nice improvement as well. Visual Studio 2015 unfortunately doesn't implement 'constexpr' well enough yet to support this change and uses a runtime fallback.
2016-01-17 21:36:36 +00:00
PYBIND11_TYPE_CASTER(bool, _("bool"));
Initial commit
2015-07-05 18:05:44 +00:00
};
Unicode fixes and docs (#624) * Propagate unicode conversion failure If returning a std::string with invalid utf-8 data, we currently fail with an uninformative TypeError instead of propagating the UnicodeDecodeError that Python sets on failure. * Add support for u16/u32strings and literals This adds support for wchar{16,32}_t character literals and the associated std::u{16,32}string types. It also folds the character/string conversion into a single type_caster template, since the type casters for string and wstring were mostly the same anyway. * Added too-long and too-big character conversion errors With this commit, when casting to a single character, as opposed to a C-style string, we make sure the input wasn't a multi-character string or a single character with codepoint too large for the character type. This also changes the character cast op to CharT instead of CharT& (we need to be able to return a temporary decoded char value, but also because there's little gained by bothering with an lvalue return here). Finally it changes the char caster to 'has-a-string-caster' instead of 'is-a-string-caster' because, with the cast_op change above, there's nothing at all gained from inheritance. This also lets us remove the `success` from the string caster (which was only there for the char caster) into the char caster itself. (I also renamed it to 'none' and inverted its value to better reflect its purpose). The None -> nullptr loading also now takes place only under a `convert = true` load pass. Although it's unlikely that a function taking a char also has overloads that can take a None, it seems marginally more correct to treat it as a conversion. This commit simplifies the size assumptions about character sizes with static_asserts to back them up.
2017-02-14 10:08:19 +00:00
// Helper class for UTF-{8,16,32} C++ stl strings:
Support std::string_view when compiled under C++17
2017-06-19 00:32:22 +00:00
template <typename StringType, bool IsView = false> struct string_caster {
using CharT = typename StringType::value_type;
Unicode fixes and docs (#624) * Propagate unicode conversion failure If returning a std::string with invalid utf-8 data, we currently fail with an uninformative TypeError instead of propagating the UnicodeDecodeError that Python sets on failure. * Add support for u16/u32strings and literals This adds support for wchar{16,32}_t character literals and the associated std::u{16,32}string types. It also folds the character/string conversion into a single type_caster template, since the type casters for string and wstring were mostly the same anyway. * Added too-long and too-big character conversion errors With this commit, when casting to a single character, as opposed to a C-style string, we make sure the input wasn't a multi-character string or a single character with codepoint too large for the character type. This also changes the character cast op to CharT instead of CharT& (we need to be able to return a temporary decoded char value, but also because there's little gained by bothering with an lvalue return here). Finally it changes the char caster to 'has-a-string-caster' instead of 'is-a-string-caster' because, with the cast_op change above, there's nothing at all gained from inheritance. This also lets us remove the `success` from the string caster (which was only there for the char caster) into the char caster itself. (I also renamed it to 'none' and inverted its value to better reflect its purpose). The None -> nullptr loading also now takes place only under a `convert = true` load pass. Although it's unlikely that a function taking a char also has overloads that can take a None, it seems marginally more correct to treat it as a conversion. This commit simplifies the size assumptions about character sizes with static_asserts to back them up.
2017-02-14 10:08:19 +00:00
// Simplify life by being able to assume standard char sizes (the standard only guarantees
Support std::string_view when compiled under C++17
2017-06-19 00:32:22 +00:00
// minimums, but Python requires exact sizes)
Unicode fixes and docs (#624) * Propagate unicode conversion failure If returning a std::string with invalid utf-8 data, we currently fail with an uninformative TypeError instead of propagating the UnicodeDecodeError that Python sets on failure. * Add support for u16/u32strings and literals This adds support for wchar{16,32}_t character literals and the associated std::u{16,32}string types. It also folds the character/string conversion into a single type_caster template, since the type casters for string and wstring were mostly the same anyway. * Added too-long and too-big character conversion errors With this commit, when casting to a single character, as opposed to a C-style string, we make sure the input wasn't a multi-character string or a single character with codepoint too large for the character type. This also changes the character cast op to CharT instead of CharT& (we need to be able to return a temporary decoded char value, but also because there's little gained by bothering with an lvalue return here). Finally it changes the char caster to 'has-a-string-caster' instead of 'is-a-string-caster' because, with the cast_op change above, there's nothing at all gained from inheritance. This also lets us remove the `success` from the string caster (which was only there for the char caster) into the char caster itself. (I also renamed it to 'none' and inverted its value to better reflect its purpose). The None -> nullptr loading also now takes place only under a `convert = true` load pass. Although it's unlikely that a function taking a char also has overloads that can take a None, it seems marginally more correct to treat it as a conversion. This commit simplifies the size assumptions about character sizes with static_asserts to back them up.
2017-02-14 10:08:19 +00:00
static_assert(!std::is_same<CharT, char>::value || sizeof(CharT) == 1, "Unsupported char size != 1");
static_assert(!std::is_same<CharT, char16_t>::value || sizeof(CharT) == 2, "Unsupported char16_t size != 2");
static_assert(!std::is_same<CharT, char32_t>::value || sizeof(CharT) == 4, "Unsupported char32_t size != 4");
// wchar_t can be either 16 bits (Windows) or 32 (everywhere else)
static_assert(!std::is_same<CharT, wchar_t>::value || sizeof(CharT) == 2 || sizeof(CharT) == 4,
"Unsupported wchar_t size != 2/4");
static constexpr size_t UTF_N = 8 * sizeof(CharT);
tabs->spaces
2016-03-26 22:38:46 +00:00
bool load(handle src, bool) {
fix python version check (#705) Commit 11a337f1 added major and minor python version checking to cast.h but does not use the macros defined via the Python.h inclusion. This may be due to an intention to use the variables defined by the cmake module FindPythonInterpreter, but nothing in the pybind11 repo does anything to convert the cmake variables to preprocessor defines.
2017-03-01 09:53:38 +00:00
#if PY_MAJOR_VERSION < 3
tabs->spaces
2016-03-26 22:38:46 +00:00
object temp;
Unicode fixes and docs (#624) * Propagate unicode conversion failure If returning a std::string with invalid utf-8 data, we currently fail with an uninformative TypeError instead of propagating the UnicodeDecodeError that Python sets on failure. * Add support for u16/u32strings and literals This adds support for wchar{16,32}_t character literals and the associated std::u{16,32}string types. It also folds the character/string conversion into a single type_caster template, since the type casters for string and wstring were mostly the same anyway. * Added too-long and too-big character conversion errors With this commit, when casting to a single character, as opposed to a C-style string, we make sure the input wasn't a multi-character string or a single character with codepoint too large for the character type. This also changes the character cast op to CharT instead of CharT& (we need to be able to return a temporary decoded char value, but also because there's little gained by bothering with an lvalue return here). Finally it changes the char caster to 'has-a-string-caster' instead of 'is-a-string-caster' because, with the cast_op change above, there's nothing at all gained from inheritance. This also lets us remove the `success` from the string caster (which was only there for the char caster) into the char caster itself. (I also renamed it to 'none' and inverted its value to better reflect its purpose). The None -> nullptr loading also now takes place only under a `convert = true` load pass. Although it's unlikely that a function taking a char also has overloads that can take a None, it seems marginally more correct to treat it as a conversion. This commit simplifies the size assumptions about character sizes with static_asserts to back them up.
2017-02-14 10:08:19 +00:00
#endif
tabs->spaces
2016-03-26 22:38:46 +00:00
handle load_src = src;
nicer type_caster::load() calling conventions
2016-05-10 14:59:01 +00:00
if (!src) {
return false;
} else if (!PyUnicode_Check(load_src.ptr())) {
fix python version check (#705) Commit 11a337f1 added major and minor python version checking to cast.h but does not use the macros defined via the Python.h inclusion. This may be due to an intention to use the variables defined by the cmake module FindPythonInterpreter, but nothing in the pybind11 repo does anything to convert the cmake variables to preprocessor defines.
2017-03-01 09:53:38 +00:00
#if PY_MAJOR_VERSION >= 3
Fix Python 3 `bytes` conversion to std::string/char* The Unicode support added in 2.1 (PR #624) inadvertently broke accepting `bytes` as std::string/char* arguments. This restores it with a separate path that does a plain conversion (i.e. completely bypassing all the encoding/decoding code), but only for single-byte string types.
2017-04-26 14:49:55 +00:00
return load_bytes(load_src);
Unicode fixes and docs (#624) * Propagate unicode conversion failure If returning a std::string with invalid utf-8 data, we currently fail with an uninformative TypeError instead of propagating the UnicodeDecodeError that Python sets on failure. * Add support for u16/u32strings and literals This adds support for wchar{16,32}_t character literals and the associated std::u{16,32}string types. It also folds the character/string conversion into a single type_caster template, since the type casters for string and wstring were mostly the same anyway. * Added too-long and too-big character conversion errors With this commit, when casting to a single character, as opposed to a C-style string, we make sure the input wasn't a multi-character string or a single character with codepoint too large for the character type. This also changes the character cast op to CharT instead of CharT& (we need to be able to return a temporary decoded char value, but also because there's little gained by bothering with an lvalue return here). Finally it changes the char caster to 'has-a-string-caster' instead of 'is-a-string-caster' because, with the cast_op change above, there's nothing at all gained from inheritance. This also lets us remove the `success` from the string caster (which was only there for the char caster) into the char caster itself. (I also renamed it to 'none' and inverted its value to better reflect its purpose). The None -> nullptr loading also now takes place only under a `convert = true` load pass. Although it's unlikely that a function taking a char also has overloads that can take a None, it seems marginally more correct to treat it as a conversion. This commit simplifies the size assumptions about character sizes with static_asserts to back them up.
2017-02-14 10:08:19 +00:00
#else
Fix passing in utf8 encoded strings with python 2 Passing utf8 encoded strings from python to a C++ function taking a std::string was broken. The previous version was trying to call 'PyUnicode_FromObject' on this data, which failed to convert the string to unicode with the default ascii codec. Also this incurs an unnecessary conversion to unicode for data this is immediately converted back to utf8. Fix by treating python 2 strings the same python 3 bytes objects, and just copying over the data if possible.
2017-06-06 19:31:41 +00:00
if (sizeof(CharT) == 1) {
return load_bytes(load_src);
}
Fix Python 3 `bytes` conversion to std::string/char* The Unicode support added in 2.1 (PR #624) inadvertently broke accepting `bytes` as std::string/char* arguments. This restores it with a separate path that does a plain conversion (i.e. completely bypassing all the encoding/decoding code), but only for single-byte string types.
2017-04-26 14:49:55 +00:00
// The below is a guaranteed failure in Python 3 when PyUnicode_Check returns false
Make string conversion stricter (#695) * Make string conversion stricter The string conversion logic added in PR #624 for all std::basic_strings was derived from the old std::wstring logic, but that was underused and turns out to have had a bug in accepting almost anything convertible to unicode, while the previous std::string logic was much stricter. This restores the previous std::string logic by only allowing actual unicode or string types. Fixes #685. * Added missing 'requires numpy' decorator (I forgot that the change to a global decorator here is in the not-yet-merged Eigen PR)
2017-02-24 10:33:31 +00:00
if (!PYBIND11_BYTES_CHECK(load_src.ptr()))
return false;
Fix passing in utf8 encoded strings with python 2 Passing utf8 encoded strings from python to a C++ function taking a std::string was broken. The previous version was trying to call 'PyUnicode_FromObject' on this data, which failed to convert the string to unicode with the default ascii codec. Also this incurs an unnecessary conversion to unicode for data this is immediately converted back to utf8. Fix by treating python 2 strings the same python 3 bytes objects, and just copying over the data if possible.
2017-06-06 19:31:41 +00:00
Add py::reinterpret_borrow<T>()/steal<T>() for low-level unchecked casts The pytype converting constructors are convenient and safe for user code, but for library internals the additional type checks and possible conversions are sometimes not desired. `reinterpret_borrow<T>()` and `reinterpret_steal<T>()` serve as the low-level unsafe counterparts of `cast<T>()`. This deprecates the `object(handle, bool)` constructor. Renamed `borrowed` parameter to `is_borrowed` to avoid shadowing warnings on MSVC.
2016-10-28 01:08:15 +00:00
temp = reinterpret_steal<object>(PyUnicode_FromObject(load_src.ptr()));
tabs->spaces
2016-03-26 22:38:46 +00:00
if (!temp) { PyErr_Clear(); return false; }
load_src = temp;
Working type casters for wide strings and wide characters
2016-03-08 18:40:32 +00:00
#endif
Unicode fixes and docs (#624) * Propagate unicode conversion failure If returning a std::string with invalid utf-8 data, we currently fail with an uninformative TypeError instead of propagating the UnicodeDecodeError that Python sets on failure. * Add support for u16/u32strings and literals This adds support for wchar{16,32}_t character literals and the associated std::u{16,32}string types. It also folds the character/string conversion into a single type_caster template, since the type casters for string and wstring were mostly the same anyway. * Added too-long and too-big character conversion errors With this commit, when casting to a single character, as opposed to a C-style string, we make sure the input wasn't a multi-character string or a single character with codepoint too large for the character type. This also changes the character cast op to CharT instead of CharT& (we need to be able to return a temporary decoded char value, but also because there's little gained by bothering with an lvalue return here). Finally it changes the char caster to 'has-a-string-caster' instead of 'is-a-string-caster' because, with the cast_op change above, there's nothing at all gained from inheritance. This also lets us remove the `success` from the string caster (which was only there for the char caster) into the char caster itself. (I also renamed it to 'none' and inverted its value to better reflect its purpose). The None -> nullptr loading also now takes place only under a `convert = true` load pass. Although it's unlikely that a function taking a char also has overloads that can take a None, it seems marginally more correct to treat it as a conversion. This commit simplifies the size assumptions about character sizes with static_asserts to back them up.
2017-02-14 10:08:19 +00:00
}
object utfNbytes = reinterpret_steal<object>(PyUnicode_AsEncodedString(
Call PyUnicode_DecodeUTF* directly Some versions of Python 2.7 reportedly (#713) have issues with PyUnicode_Decode being passed the encoding string, so just skip it entirely by calling the PyUnicode_DecodeUTF* function directly. This will also be slightly more efficient by avoiding having to check the encoding string, and (for python 2) going through the unicode class's decode (python 3 fast-tracks this for all utf-{8,16,32} encodings; python 2 only fast-tracked for the exact string "utf-8", which we weren't passing anyway (we had "utf8")). This doesn't work for PyPy, however: its `PyUnicode_DecodeUTF{8,16,32}` appear rather broken: the UTF8 one segfaults, while the 16/32 require recasting into a non-const `char *` (and might segfault; I didn't get far enough to find out). Just avoid the whole thing by keeping the encoding-passed-as-string version for PyPy, which seems to work reliably.
2017-03-09 16:35:28 +00:00
load_src.ptr(), UTF_N == 8 ? "utf-8" : UTF_N == 16 ? "utf-16" : "utf-32", nullptr));
Unicode fixes and docs (#624) * Propagate unicode conversion failure If returning a std::string with invalid utf-8 data, we currently fail with an uninformative TypeError instead of propagating the UnicodeDecodeError that Python sets on failure. * Add support for u16/u32strings and literals This adds support for wchar{16,32}_t character literals and the associated std::u{16,32}string types. It also folds the character/string conversion into a single type_caster template, since the type casters for string and wstring were mostly the same anyway. * Added too-long and too-big character conversion errors With this commit, when casting to a single character, as opposed to a C-style string, we make sure the input wasn't a multi-character string or a single character with codepoint too large for the character type. This also changes the character cast op to CharT instead of CharT& (we need to be able to return a temporary decoded char value, but also because there's little gained by bothering with an lvalue return here). Finally it changes the char caster to 'has-a-string-caster' instead of 'is-a-string-caster' because, with the cast_op change above, there's nothing at all gained from inheritance. This also lets us remove the `success` from the string caster (which was only there for the char caster) into the char caster itself. (I also renamed it to 'none' and inverted its value to better reflect its purpose). The None -> nullptr loading also now takes place only under a `convert = true` load pass. Although it's unlikely that a function taking a char also has overloads that can take a None, it seems marginally more correct to treat it as a conversion. This commit simplifies the size assumptions about character sizes with static_asserts to back them up.
2017-02-14 10:08:19 +00:00
if (!utfNbytes) { PyErr_Clear(); return false; }
const CharT *buffer = reinterpret_cast<const CharT *>(PYBIND11_BYTES_AS_STRING(utfNbytes.ptr()));
size_t length = (size_t) PYBIND11_BYTES_SIZE(utfNbytes.ptr()) / sizeof(CharT);
if (UTF_N > 8) { buffer++; length--; } // Skip BOM for UTF-16/32
value = StringType(buffer, length);
Support std::string_view when compiled under C++17
2017-06-19 00:32:22 +00:00
// If we're loading a string_view we need to keep the encoded Python object alive:
if (IsView)
Add a life support system for type_caster temporaries
2017-06-26 18:34:06 +00:00
loader_life_support::add_patient(utfNbytes);
Support std::string_view when compiled under C++17
2017-06-19 00:32:22 +00:00
tabs->spaces
2016-03-26 22:38:46 +00:00
return true;
}
add wstring caster
2016-03-02 05:59:39 +00:00
Unicode fixes and docs (#624) * Propagate unicode conversion failure If returning a std::string with invalid utf-8 data, we currently fail with an uninformative TypeError instead of propagating the UnicodeDecodeError that Python sets on failure. * Add support for u16/u32strings and literals This adds support for wchar{16,32}_t character literals and the associated std::u{16,32}string types. It also folds the character/string conversion into a single type_caster template, since the type casters for string and wstring were mostly the same anyway. * Added too-long and too-big character conversion errors With this commit, when casting to a single character, as opposed to a C-style string, we make sure the input wasn't a multi-character string or a single character with codepoint too large for the character type. This also changes the character cast op to CharT instead of CharT& (we need to be able to return a temporary decoded char value, but also because there's little gained by bothering with an lvalue return here). Finally it changes the char caster to 'has-a-string-caster' instead of 'is-a-string-caster' because, with the cast_op change above, there's nothing at all gained from inheritance. This also lets us remove the `success` from the string caster (which was only there for the char caster) into the char caster itself. (I also renamed it to 'none' and inverted its value to better reflect its purpose). The None -> nullptr loading also now takes place only under a `convert = true` load pass. Although it's unlikely that a function taking a char also has overloads that can take a None, it seems marginally more correct to treat it as a conversion. This commit simplifies the size assumptions about character sizes with static_asserts to back them up.
2017-02-14 10:08:19 +00:00
static handle cast(const StringType &src, return_value_policy /* policy */, handle /* parent */) {
Support std::string_view when compiled under C++17
2017-06-19 00:32:22 +00:00
const char *buffer = reinterpret_cast<const char *>(src.data());
Unicode fixes and docs (#624) * Propagate unicode conversion failure If returning a std::string with invalid utf-8 data, we currently fail with an uninformative TypeError instead of propagating the UnicodeDecodeError that Python sets on failure. * Add support for u16/u32strings and literals This adds support for wchar{16,32}_t character literals and the associated std::u{16,32}string types. It also folds the character/string conversion into a single type_caster template, since the type casters for string and wstring were mostly the same anyway. * Added too-long and too-big character conversion errors With this commit, when casting to a single character, as opposed to a C-style string, we make sure the input wasn't a multi-character string or a single character with codepoint too large for the character type. This also changes the character cast op to CharT instead of CharT& (we need to be able to return a temporary decoded char value, but also because there's little gained by bothering with an lvalue return here). Finally it changes the char caster to 'has-a-string-caster' instead of 'is-a-string-caster' because, with the cast_op change above, there's nothing at all gained from inheritance. This also lets us remove the `success` from the string caster (which was only there for the char caster) into the char caster itself. (I also renamed it to 'none' and inverted its value to better reflect its purpose). The None -> nullptr loading also now takes place only under a `convert = true` load pass. Although it's unlikely that a function taking a char also has overloads that can take a None, it seems marginally more correct to treat it as a conversion. This commit simplifies the size assumptions about character sizes with static_asserts to back them up.
2017-02-14 10:08:19 +00:00
ssize_t nbytes = ssize_t(src.size() * sizeof(CharT));
Call PyUnicode_DecodeUTF* directly Some versions of Python 2.7 reportedly (#713) have issues with PyUnicode_Decode being passed the encoding string, so just skip it entirely by calling the PyUnicode_DecodeUTF* function directly. This will also be slightly more efficient by avoiding having to check the encoding string, and (for python 2) going through the unicode class's decode (python 3 fast-tracks this for all utf-{8,16,32} encodings; python 2 only fast-tracked for the exact string "utf-8", which we weren't passing anyway (we had "utf8")). This doesn't work for PyPy, however: its `PyUnicode_DecodeUTF{8,16,32}` appear rather broken: the UTF8 one segfaults, while the 16/32 require recasting into a non-const `char *` (and might segfault; I didn't get far enough to find out). Just avoid the whole thing by keeping the encoding-passed-as-string version for PyPy, which seems to work reliably.
2017-03-09 16:35:28 +00:00
handle s = decode_utfN(buffer, nbytes);
Unicode fixes and docs (#624) * Propagate unicode conversion failure If returning a std::string with invalid utf-8 data, we currently fail with an uninformative TypeError instead of propagating the UnicodeDecodeError that Python sets on failure. * Add support for u16/u32strings and literals This adds support for wchar{16,32}_t character literals and the associated std::u{16,32}string types. It also folds the character/string conversion into a single type_caster template, since the type casters for string and wstring were mostly the same anyway. * Added too-long and too-big character conversion errors With this commit, when casting to a single character, as opposed to a C-style string, we make sure the input wasn't a multi-character string or a single character with codepoint too large for the character type. This also changes the character cast op to CharT instead of CharT& (we need to be able to return a temporary decoded char value, but also because there's little gained by bothering with an lvalue return here). Finally it changes the char caster to 'has-a-string-caster' instead of 'is-a-string-caster' because, with the cast_op change above, there's nothing at all gained from inheritance. This also lets us remove the `success` from the string caster (which was only there for the char caster) into the char caster itself. (I also renamed it to 'none' and inverted its value to better reflect its purpose). The None -> nullptr loading also now takes place only under a `convert = true` load pass. Although it's unlikely that a function taking a char also has overloads that can take a None, it seems marginally more correct to treat it as a conversion. This commit simplifies the size assumptions about character sizes with static_asserts to back them up.
2017-02-14 10:08:19 +00:00
if (!s) throw error_already_set();
return s;
tabs->spaces
2016-03-26 22:38:46 +00:00
}
Initial commit
2015-07-05 18:05:44 +00:00
Unicode fixes and docs (#624) * Propagate unicode conversion failure If returning a std::string with invalid utf-8 data, we currently fail with an uninformative TypeError instead of propagating the UnicodeDecodeError that Python sets on failure. * Add support for u16/u32strings and literals This adds support for wchar{16,32}_t character literals and the associated std::u{16,32}string types. It also folds the character/string conversion into a single type_caster template, since the type casters for string and wstring were mostly the same anyway. * Added too-long and too-big character conversion errors With this commit, when casting to a single character, as opposed to a C-style string, we make sure the input wasn't a multi-character string or a single character with codepoint too large for the character type. This also changes the character cast op to CharT instead of CharT& (we need to be able to return a temporary decoded char value, but also because there's little gained by bothering with an lvalue return here). Finally it changes the char caster to 'has-a-string-caster' instead of 'is-a-string-caster' because, with the cast_op change above, there's nothing at all gained from inheritance. This also lets us remove the `success` from the string caster (which was only there for the char caster) into the char caster itself. (I also renamed it to 'none' and inverted its value to better reflect its purpose). The None -> nullptr loading also now takes place only under a `convert = true` load pass. Although it's unlikely that a function taking a char also has overloads that can take a None, it seems marginally more correct to treat it as a conversion. This commit simplifies the size assumptions about character sizes with static_asserts to back them up.
2017-02-14 10:08:19 +00:00
PYBIND11_TYPE_CASTER(StringType, _(PYBIND11_STRING_NAME));
Call PyUnicode_DecodeUTF* directly Some versions of Python 2.7 reportedly (#713) have issues with PyUnicode_Decode being passed the encoding string, so just skip it entirely by calling the PyUnicode_DecodeUTF* function directly. This will also be slightly more efficient by avoiding having to check the encoding string, and (for python 2) going through the unicode class's decode (python 3 fast-tracks this for all utf-{8,16,32} encodings; python 2 only fast-tracked for the exact string "utf-8", which we weren't passing anyway (we had "utf8")). This doesn't work for PyPy, however: its `PyUnicode_DecodeUTF{8,16,32}` appear rather broken: the UTF8 one segfaults, while the 16/32 require recasting into a non-const `char *` (and might segfault; I didn't get far enough to find out). Just avoid the whole thing by keeping the encoding-passed-as-string version for PyPy, which seems to work reliably.
2017-03-09 16:35:28 +00:00
private:
static handle decode_utfN(const char *buffer, ssize_t nbytes) {
#if !defined(PYPY_VERSION)
return
UTF_N == 8 ? PyUnicode_DecodeUTF8(buffer, nbytes, nullptr) :
UTF_N == 16 ? PyUnicode_DecodeUTF16(buffer, nbytes, nullptr, nullptr) :
PyUnicode_DecodeUTF32(buffer, nbytes, nullptr, nullptr);
#else
// PyPy seems to have multiple problems related to PyUnicode_UTF*: the UTF8 version
// sometimes segfaults for unknown reasons, while the UTF16 and 32 versions require a
Misc. typos (#1384) Found via `codespell`
2018-05-06 13:54:10 +00:00
// non-const char * arguments, which is also a nuisance, so bypass the whole thing by just
Call PyUnicode_DecodeUTF* directly Some versions of Python 2.7 reportedly (#713) have issues with PyUnicode_Decode being passed the encoding string, so just skip it entirely by calling the PyUnicode_DecodeUTF* function directly. This will also be slightly more efficient by avoiding having to check the encoding string, and (for python 2) going through the unicode class's decode (python 3 fast-tracks this for all utf-{8,16,32} encodings; python 2 only fast-tracked for the exact string "utf-8", which we weren't passing anyway (we had "utf8")). This doesn't work for PyPy, however: its `PyUnicode_DecodeUTF{8,16,32}` appear rather broken: the UTF8 one segfaults, while the 16/32 require recasting into a non-const `char *` (and might segfault; I didn't get far enough to find out). Just avoid the whole thing by keeping the encoding-passed-as-string version for PyPy, which seems to work reliably.
2017-03-09 16:35:28 +00:00
// passing the encoding as a string value, which works properly:
return PyUnicode_Decode(buffer, nbytes, UTF_N == 8 ? "utf-8" : UTF_N == 16 ? "utf-16" : "utf-32", nullptr);
#endif
}
Fix Python 3 `bytes` conversion to std::string/char* The Unicode support added in 2.1 (PR #624) inadvertently broke accepting `bytes` as std::string/char* arguments. This restores it with a separate path that does a plain conversion (i.e. completely bypassing all the encoding/decoding code), but only for single-byte string types.
2017-04-26 14:49:55 +00:00
Fix passing in utf8 encoded strings with python 2 Passing utf8 encoded strings from python to a C++ function taking a std::string was broken. The previous version was trying to call 'PyUnicode_FromObject' on this data, which failed to convert the string to unicode with the default ascii codec. Also this incurs an unnecessary conversion to unicode for data this is immediately converted back to utf8. Fix by treating python 2 strings the same python 3 bytes objects, and just copying over the data if possible.
2017-06-06 19:31:41 +00:00
// When loading into a std::string or char*, accept a bytes object as-is (i.e.
// without any encoding/decoding attempt). For other C++ char sizes this is a no-op.
Fix Python 3 `bytes` conversion to std::string/char* The Unicode support added in 2.1 (PR #624) inadvertently broke accepting `bytes` as std::string/char* arguments. This restores it with a separate path that does a plain conversion (i.e. completely bypassing all the encoding/decoding code), but only for single-byte string types.
2017-04-26 14:49:55 +00:00
// which supports loading a unicode from a str, doesn't take this path.
template <typename C = CharT>
bool load_bytes(enable_if_t<sizeof(C) == 1, handle> src) {
if (PYBIND11_BYTES_CHECK(src.ptr())) {
// We were passed a Python 3 raw bytes; accept it into a std::string or char*
// without any encoding attempt.
const char *bytes = PYBIND11_BYTES_AS_STRING(src.ptr());
if (bytes) {
value = StringType(bytes, (size_t) PYBIND11_BYTES_SIZE(src.ptr()));
return true;
}
}
return false;
}
Fix passing in utf8 encoded strings with python 2 Passing utf8 encoded strings from python to a C++ function taking a std::string was broken. The previous version was trying to call 'PyUnicode_FromObject' on this data, which failed to convert the string to unicode with the default ascii codec. Also this incurs an unnecessary conversion to unicode for data this is immediately converted back to utf8. Fix by treating python 2 strings the same python 3 bytes objects, and just copying over the data if possible.
2017-06-06 19:31:41 +00:00
Fix Python 3 `bytes` conversion to std::string/char* The Unicode support added in 2.1 (PR #624) inadvertently broke accepting `bytes` as std::string/char* arguments. This restores it with a separate path that does a plain conversion (i.e. completely bypassing all the encoding/decoding code), but only for single-byte string types.
2017-04-26 14:49:55 +00:00
template <typename C = CharT>
bool load_bytes(enable_if_t<sizeof(C) != 1, handle>) { return false; }
add wstring caster
2016-03-02 05:59:39 +00:00
};
Support std::string_view when compiled under C++17
2017-06-19 00:32:22 +00:00
template <typename CharT, class Traits, class Allocator>
struct type_caster<std::basic_string<CharT, Traits, Allocator>, enable_if_t<is_std_char_type<CharT>::value>>
: string_caster<std::basic_string<CharT, Traits, Allocator>> {};
#ifdef PYBIND11_HAS_STRING_VIEW
template <typename CharT, class Traits>
struct type_caster<std::basic_string_view<CharT, Traits>, enable_if_t<is_std_char_type<CharT>::value>>
: string_caster<std::basic_string_view<CharT, Traits>, true> {};
#endif
Unicode fixes and docs (#624) * Propagate unicode conversion failure If returning a std::string with invalid utf-8 data, we currently fail with an uninformative TypeError instead of propagating the UnicodeDecodeError that Python sets on failure. * Add support for u16/u32strings and literals This adds support for wchar{16,32}_t character literals and the associated std::u{16,32}string types. It also folds the character/string conversion into a single type_caster template, since the type casters for string and wstring were mostly the same anyway. * Added too-long and too-big character conversion errors With this commit, when casting to a single character, as opposed to a C-style string, we make sure the input wasn't a multi-character string or a single character with codepoint too large for the character type. This also changes the character cast op to CharT instead of CharT& (we need to be able to return a temporary decoded char value, but also because there's little gained by bothering with an lvalue return here). Finally it changes the char caster to 'has-a-string-caster' instead of 'is-a-string-caster' because, with the cast_op change above, there's nothing at all gained from inheritance. This also lets us remove the `success` from the string caster (which was only there for the char caster) into the char caster itself. (I also renamed it to 'none' and inverted its value to better reflect its purpose). The None -> nullptr loading also now takes place only under a `convert = true` load pass. Although it's unlikely that a function taking a char also has overloads that can take a None, it seems marginally more correct to treat it as a conversion. This commit simplifies the size assumptions about character sizes with static_asserts to back them up.
2017-02-14 10:08:19 +00:00
// Type caster for C-style strings. We basically use a std::string type caster, but also add the
// ability to use None as a nullptr char* (which the string caster doesn't allow).
template <typename CharT> struct type_caster<CharT, enable_if_t<is_std_char_type<CharT>::value>> {
using StringType = std::basic_string<CharT>;
using StringCaster = type_caster<StringType>;
StringCaster str_caster;
bool none = false;
Fix `char &` arguments being non-bindable This changes the caster to return a reference to a (new) local `CharT` type caster member so that binding lvalue-reference char arguments works (currently it results in a compilation failure). Fixes #1116
2017-10-06 14:50:10 +00:00
CharT one_char = 0;
Initial commit
2015-07-05 18:05:44 +00:00
public:
tabs->spaces
2016-03-26 22:38:46 +00:00
bool load(handle src, bool convert) {
Unicode fixes and docs (#624) * Propagate unicode conversion failure If returning a std::string with invalid utf-8 data, we currently fail with an uninformative TypeError instead of propagating the UnicodeDecodeError that Python sets on failure. * Add support for u16/u32strings and literals This adds support for wchar{16,32}_t character literals and the associated std::u{16,32}string types. It also folds the character/string conversion into a single type_caster template, since the type casters for string and wstring were mostly the same anyway. * Added too-long and too-big character conversion errors With this commit, when casting to a single character, as opposed to a C-style string, we make sure the input wasn't a multi-character string or a single character with codepoint too large for the character type. This also changes the character cast op to CharT instead of CharT& (we need to be able to return a temporary decoded char value, but also because there's little gained by bothering with an lvalue return here). Finally it changes the char caster to 'has-a-string-caster' instead of 'is-a-string-caster' because, with the cast_op change above, there's nothing at all gained from inheritance. This also lets us remove the `success` from the string caster (which was only there for the char caster) into the char caster itself. (I also renamed it to 'none' and inverted its value to better reflect its purpose). The None -> nullptr loading also now takes place only under a `convert = true` load pass. Although it's unlikely that a function taking a char also has overloads that can take a None, it seems marginally more correct to treat it as a conversion. This commit simplifies the size assumptions about character sizes with static_asserts to back them up.
2017-02-14 10:08:19 +00:00
if (!src) return false;
if (src.is_none()) {
// Defer accepting None to other overloads (if we aren't in convert mode):
if (!convert) return false;
none = true;
return true;
}
return str_caster.load(src, convert);
allow nullptr string values (closes #138)
2016-03-26 22:37:51 +00:00
}
Unicode fixes and docs (#624) * Propagate unicode conversion failure If returning a std::string with invalid utf-8 data, we currently fail with an uninformative TypeError instead of propagating the UnicodeDecodeError that Python sets on failure. * Add support for u16/u32strings and literals This adds support for wchar{16,32}_t character literals and the associated std::u{16,32}string types. It also folds the character/string conversion into a single type_caster template, since the type casters for string and wstring were mostly the same anyway. * Added too-long and too-big character conversion errors With this commit, when casting to a single character, as opposed to a C-style string, we make sure the input wasn't a multi-character string or a single character with codepoint too large for the character type. This also changes the character cast op to CharT instead of CharT& (we need to be able to return a temporary decoded char value, but also because there's little gained by bothering with an lvalue return here). Finally it changes the char caster to 'has-a-string-caster' instead of 'is-a-string-caster' because, with the cast_op change above, there's nothing at all gained from inheritance. This also lets us remove the `success` from the string caster (which was only there for the char caster) into the char caster itself. (I also renamed it to 'none' and inverted its value to better reflect its purpose). The None -> nullptr loading also now takes place only under a `convert = true` load pass. Although it's unlikely that a function taking a char also has overloads that can take a None, it seems marginally more correct to treat it as a conversion. This commit simplifies the size assumptions about character sizes with static_asserts to back them up.
2017-02-14 10:08:19 +00:00
static handle cast(const CharT *src, return_value_policy policy, handle parent) {
if (src == nullptr) return pybind11::none().inc_ref();
return StringCaster::cast(StringType(src), policy, parent);
Initial commit
2015-07-05 18:05:44 +00:00
}
Unicode fixes and docs (#624) * Propagate unicode conversion failure If returning a std::string with invalid utf-8 data, we currently fail with an uninformative TypeError instead of propagating the UnicodeDecodeError that Python sets on failure. * Add support for u16/u32strings and literals This adds support for wchar{16,32}_t character literals and the associated std::u{16,32}string types. It also folds the character/string conversion into a single type_caster template, since the type casters for string and wstring were mostly the same anyway. * Added too-long and too-big character conversion errors With this commit, when casting to a single character, as opposed to a C-style string, we make sure the input wasn't a multi-character string or a single character with codepoint too large for the character type. This also changes the character cast op to CharT instead of CharT& (we need to be able to return a temporary decoded char value, but also because there's little gained by bothering with an lvalue return here). Finally it changes the char caster to 'has-a-string-caster' instead of 'is-a-string-caster' because, with the cast_op change above, there's nothing at all gained from inheritance. This also lets us remove the `success` from the string caster (which was only there for the char caster) into the char caster itself. (I also renamed it to 'none' and inverted its value to better reflect its purpose). The None -> nullptr loading also now takes place only under a `convert = true` load pass. Although it's unlikely that a function taking a char also has overloads that can take a None, it seems marginally more correct to treat it as a conversion. This commit simplifies the size assumptions about character sizes with static_asserts to back them up.
2017-02-14 10:08:19 +00:00
static handle cast(CharT src, return_value_policy policy, handle parent) {
if (std::is_same<char, CharT>::value) {
handle s = PyUnicode_DecodeLatin1((const char *) &src, 1, nullptr);
if (!s) throw error_already_set();
return s;
}
return StringCaster::cast(StringType(1, src), policy, parent);
Initial commit
2015-07-05 18:05:44 +00:00
}
Unicode fixes and docs (#624) * Propagate unicode conversion failure If returning a std::string with invalid utf-8 data, we currently fail with an uninformative TypeError instead of propagating the UnicodeDecodeError that Python sets on failure. * Add support for u16/u32strings and literals This adds support for wchar{16,32}_t character literals and the associated std::u{16,32}string types. It also folds the character/string conversion into a single type_caster template, since the type casters for string and wstring were mostly the same anyway. * Added too-long and too-big character conversion errors With this commit, when casting to a single character, as opposed to a C-style string, we make sure the input wasn't a multi-character string or a single character with codepoint too large for the character type. This also changes the character cast op to CharT instead of CharT& (we need to be able to return a temporary decoded char value, but also because there's little gained by bothering with an lvalue return here). Finally it changes the char caster to 'has-a-string-caster' instead of 'is-a-string-caster' because, with the cast_op change above, there's nothing at all gained from inheritance. This also lets us remove the `success` from the string caster (which was only there for the char caster) into the char caster itself. (I also renamed it to 'none' and inverted its value to better reflect its purpose). The None -> nullptr loading also now takes place only under a `convert = true` load pass. Although it's unlikely that a function taking a char also has overloads that can take a None, it seems marginally more correct to treat it as a conversion. This commit simplifies the size assumptions about character sizes with static_asserts to back them up.
2017-02-14 10:08:19 +00:00
operator CharT*() { return none ? nullptr : const_cast<CharT *>(static_cast<StringType &>(str_caster).c_str()); }
Fix `char &` arguments being non-bindable This changes the caster to return a reference to a (new) local `CharT` type caster member so that binding lvalue-reference char arguments works (currently it results in a compilation failure). Fixes #1116
2017-10-06 14:50:10 +00:00
operator CharT&() {
Unicode fixes and docs (#624) * Propagate unicode conversion failure If returning a std::string with invalid utf-8 data, we currently fail with an uninformative TypeError instead of propagating the UnicodeDecodeError that Python sets on failure. * Add support for u16/u32strings and literals This adds support for wchar{16,32}_t character literals and the associated std::u{16,32}string types. It also folds the character/string conversion into a single type_caster template, since the type casters for string and wstring were mostly the same anyway. * Added too-long and too-big character conversion errors With this commit, when casting to a single character, as opposed to a C-style string, we make sure the input wasn't a multi-character string or a single character with codepoint too large for the character type. This also changes the character cast op to CharT instead of CharT& (we need to be able to return a temporary decoded char value, but also because there's little gained by bothering with an lvalue return here). Finally it changes the char caster to 'has-a-string-caster' instead of 'is-a-string-caster' because, with the cast_op change above, there's nothing at all gained from inheritance. This also lets us remove the `success` from the string caster (which was only there for the char caster) into the char caster itself. (I also renamed it to 'none' and inverted its value to better reflect its purpose). The None -> nullptr loading also now takes place only under a `convert = true` load pass. Although it's unlikely that a function taking a char also has overloads that can take a None, it seems marginally more correct to treat it as a conversion. This commit simplifies the size assumptions about character sizes with static_asserts to back them up.
2017-02-14 10:08:19 +00:00
if (none)
throw value_error("Cannot convert None to a character");
auto &value = static_cast<StringType &>(str_caster);
size_t str_len = value.size();
if (str_len == 0)
throw value_error("Cannot convert empty string to a character");
// If we're in UTF-8 mode, we have two possible failures: one for a unicode character that
// is too high, and one for multiple unicode characters (caught later), so we need to figure
// out how long the first encoded character is in bytes to distinguish between these two
// errors. We also allow want to allow unicode characters U+0080 through U+00FF, as those
// can fit into a single char value.
if (StringCaster::UTF_N == 8 && str_len > 1 && str_len <= 4) {
unsigned char v0 = static_cast<unsigned char>(value[0]);
size_t char0_bytes = !(v0 & 0x80) ? 1 : // low bits only: 0-127
(v0 & 0xE0) == 0xC0 ? 2 : // 0b110xxxxx - start of 2-byte sequence
(v0 & 0xF0) == 0xE0 ? 3 : // 0b1110xxxx - start of 3-byte sequence
4; // 0b11110xxx - start of 4-byte sequence
if (char0_bytes == str_len) {
// If we have a 128-255 value, we can decode it into a single char:
if (char0_bytes == 2 && (v0 & 0xFC) == 0xC0) { // 0x110000xx 0x10xxxxxx
Fix `char &` arguments being non-bindable This changes the caster to return a reference to a (new) local `CharT` type caster member so that binding lvalue-reference char arguments works (currently it results in a compilation failure). Fixes #1116
2017-10-06 14:50:10 +00:00
one_char = static_cast<CharT>(((v0 & 3) << 6) + (static_cast<unsigned char>(value[1]) & 0x3F));
return one_char;
Unicode fixes and docs (#624) * Propagate unicode conversion failure If returning a std::string with invalid utf-8 data, we currently fail with an uninformative TypeError instead of propagating the UnicodeDecodeError that Python sets on failure. * Add support for u16/u32strings and literals This adds support for wchar{16,32}_t character literals and the associated std::u{16,32}string types. It also folds the character/string conversion into a single type_caster template, since the type casters for string and wstring were mostly the same anyway. * Added too-long and too-big character conversion errors With this commit, when casting to a single character, as opposed to a C-style string, we make sure the input wasn't a multi-character string or a single character with codepoint too large for the character type. This also changes the character cast op to CharT instead of CharT& (we need to be able to return a temporary decoded char value, but also because there's little gained by bothering with an lvalue return here). Finally it changes the char caster to 'has-a-string-caster' instead of 'is-a-string-caster' because, with the cast_op change above, there's nothing at all gained from inheritance. This also lets us remove the `success` from the string caster (which was only there for the char caster) into the char caster itself. (I also renamed it to 'none' and inverted its value to better reflect its purpose). The None -> nullptr loading also now takes place only under a `convert = true` load pass. Although it's unlikely that a function taking a char also has overloads that can take a None, it seems marginally more correct to treat it as a conversion. This commit simplifies the size assumptions about character sizes with static_asserts to back them up.
2017-02-14 10:08:19 +00:00
}
// Otherwise we have a single character, but it's > U+00FF
throw value_error("Character code point not in range(0x100)");
}
}
Initial commit
2015-07-05 18:05:44 +00:00
Unicode fixes and docs (#624) * Propagate unicode conversion failure If returning a std::string with invalid utf-8 data, we currently fail with an uninformative TypeError instead of propagating the UnicodeDecodeError that Python sets on failure. * Add support for u16/u32strings and literals This adds support for wchar{16,32}_t character literals and the associated std::u{16,32}string types. It also folds the character/string conversion into a single type_caster template, since the type casters for string and wstring were mostly the same anyway. * Added too-long and too-big character conversion errors With this commit, when casting to a single character, as opposed to a C-style string, we make sure the input wasn't a multi-character string or a single character with codepoint too large for the character type. This also changes the character cast op to CharT instead of CharT& (we need to be able to return a temporary decoded char value, but also because there's little gained by bothering with an lvalue return here). Finally it changes the char caster to 'has-a-string-caster' instead of 'is-a-string-caster' because, with the cast_op change above, there's nothing at all gained from inheritance. This also lets us remove the `success` from the string caster (which was only there for the char caster) into the char caster itself. (I also renamed it to 'none' and inverted its value to better reflect its purpose). The None -> nullptr loading also now takes place only under a `convert = true` load pass. Although it's unlikely that a function taking a char also has overloads that can take a None, it seems marginally more correct to treat it as a conversion. This commit simplifies the size assumptions about character sizes with static_asserts to back them up.
2017-02-14 10:08:19 +00:00
// UTF-16 is much easier: we can only have a surrogate pair for values above U+FFFF, thus a
// surrogate pair with total length 2 instantly indicates a range error (but not a "your
// string was too long" error).
else if (StringCaster::UTF_N == 16 && str_len == 2) {
Fix `char &` arguments being non-bindable This changes the caster to return a reference to a (new) local `CharT` type caster member so that binding lvalue-reference char arguments works (currently it results in a compilation failure). Fixes #1116
2017-10-06 14:50:10 +00:00
one_char = static_cast<CharT>(value[0]);
if (one_char >= 0xD800 && one_char < 0xE000)
Unicode fixes and docs (#624) * Propagate unicode conversion failure If returning a std::string with invalid utf-8 data, we currently fail with an uninformative TypeError instead of propagating the UnicodeDecodeError that Python sets on failure. * Add support for u16/u32strings and literals This adds support for wchar{16,32}_t character literals and the associated std::u{16,32}string types. It also folds the character/string conversion into a single type_caster template, since the type casters for string and wstring were mostly the same anyway. * Added too-long and too-big character conversion errors With this commit, when casting to a single character, as opposed to a C-style string, we make sure the input wasn't a multi-character string or a single character with codepoint too large for the character type. This also changes the character cast op to CharT instead of CharT& (we need to be able to return a temporary decoded char value, but also because there's little gained by bothering with an lvalue return here). Finally it changes the char caster to 'has-a-string-caster' instead of 'is-a-string-caster' because, with the cast_op change above, there's nothing at all gained from inheritance. This also lets us remove the `success` from the string caster (which was only there for the char caster) into the char caster itself. (I also renamed it to 'none' and inverted its value to better reflect its purpose). The None -> nullptr loading also now takes place only under a `convert = true` load pass. Although it's unlikely that a function taking a char also has overloads that can take a None, it seems marginally more correct to treat it as a conversion. This commit simplifies the size assumptions about character sizes with static_asserts to back them up.
2017-02-14 10:08:19 +00:00
throw value_error("Character code point not in range(0x10000)");
}
allow nullptr string values (closes #138)
2016-03-26 22:37:51 +00:00
Unicode fixes and docs (#624) * Propagate unicode conversion failure If returning a std::string with invalid utf-8 data, we currently fail with an uninformative TypeError instead of propagating the UnicodeDecodeError that Python sets on failure. * Add support for u16/u32strings and literals This adds support for wchar{16,32}_t character literals and the associated std::u{16,32}string types. It also folds the character/string conversion into a single type_caster template, since the type casters for string and wstring were mostly the same anyway. * Added too-long and too-big character conversion errors With this commit, when casting to a single character, as opposed to a C-style string, we make sure the input wasn't a multi-character string or a single character with codepoint too large for the character type. This also changes the character cast op to CharT instead of CharT& (we need to be able to return a temporary decoded char value, but also because there's little gained by bothering with an lvalue return here). Finally it changes the char caster to 'has-a-string-caster' instead of 'is-a-string-caster' because, with the cast_op change above, there's nothing at all gained from inheritance. This also lets us remove the `success` from the string caster (which was only there for the char caster) into the char caster itself. (I also renamed it to 'none' and inverted its value to better reflect its purpose). The None -> nullptr loading also now takes place only under a `convert = true` load pass. Although it's unlikely that a function taking a char also has overloads that can take a None, it seems marginally more correct to treat it as a conversion. This commit simplifies the size assumptions about character sizes with static_asserts to back them up.
2017-02-14 10:08:19 +00:00
if (str_len != 1)
throw value_error("Expected a character, but multi-character string found");
add wchar_t caster
2016-03-02 07:07:08 +00:00
Fix `char &` arguments being non-bindable This changes the caster to return a reference to a (new) local `CharT` type caster member so that binding lvalue-reference char arguments works (currently it results in a compilation failure). Fixes #1116
2017-10-06 14:50:10 +00:00
one_char = value[0];
return one_char;
tabs->spaces
2016-03-26 22:38:46 +00:00
}
add wchar_t caster
2016-03-02 07:07:08 +00:00
Simplify function signature annotation and parsing `type_descr` is now applied only to the final signature so that it only marks the argument types, but not nested types (e.g. for tuples) or return types.
2017-08-31 12:38:23 +00:00
static constexpr auto name = _(PYBIND11_STRING_NAME);
Fix `char &` arguments being non-bindable This changes the caster to return a reference to a (new) local `CharT` type caster member so that binding lvalue-reference char arguments works (currently it results in a compilation failure). Fixes #1116
2017-10-06 14:50:10 +00:00
template <typename _T> using cast_op_type = pybind11::detail::cast_op_type<_T>;
add wchar_t caster
2016-03-02 07:07:08 +00:00
};
Combine std::tuple/std::pair logic The std::pair caster can be written as a special case of the std::tuple caster; this combines them via a base `tuple_caster` class (which is essentially identical to the previous std::tuple caster). This also removes the special empty tuple base case: returning an empty tuple is relatively rare, and the base case still works perfectly well even when the tuple types is an empty list.
2017-07-04 18:57:41 +00:00
// Base implementation for std::tuple and std::pair
Use rvalue subcasting when casting an rvalue container This updates the std::tuple, std::pair and `stl.h` type casters to forward their contained value according to whether the container being cast is an lvalue or rvalue reference. This fixes an issue where subcaster casts were always called with a const lvalue which meant nested type casters didn't have the desired `cast()` overload invoked. For example, this caused Eigen values in a tuple to end up with a readonly flag (issue #935) and made it impossible to return a container of move-only types (issue #853). This fixes both issues by adding templated universal reference `cast()` methods to the various container types that forward container elements according to the container reference type.
2017-07-03 23:12:09 +00:00
template <template<typename...> class Tuple, typename... Ts> class tuple_caster {
using type = Tuple<Ts...>;
static constexpr auto size = sizeof...(Ts);
Combine std::tuple/std::pair logic The std::pair caster can be written as a special case of the std::tuple caster; this combines them via a base `tuple_caster` class (which is essentially identical to the previous std::tuple caster). This also removes the special empty tuple base case: returning an empty tuple is relatively rare, and the base case still works perfectly well even when the tuple types is an empty list.
2017-07-04 18:57:41 +00:00
using indices = make_index_sequence<size>;
Split up tuple caster and function argument loader This is needed in order to allow the tuple caster to accept any sequence while keeping the argument loader fast. There is also very little overlap between the two classes which makes the separation clean. It’s also good practice not to have completely new functionality in a specialization.
2016-11-27 17:19:34 +00:00
public:
Combine std::tuple/std::pair logic The std::pair caster can be written as a special case of the std::tuple caster; this combines them via a base `tuple_caster` class (which is essentially identical to the previous std::tuple caster). This also removes the special empty tuple base case: returning an empty tuple is relatively rare, and the base case still works perfectly well even when the tuple types is an empty list.
2017-07-04 18:57:41 +00:00
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
bool load(handle src, bool convert) {
Accept any sequence type as std::tuple or std::pair This is more Pythonic and compliments the std::vector and std::list casters which also accept sequences.
2016-11-27 19:32:04 +00:00
if (!isinstance<sequence>(src))
return false;
const auto seq = reinterpret_borrow<sequence>(src);
if (seq.size() != size)
nicer type_caster::load() calling conventions
2016-05-10 14:59:01 +00:00
return false;
Accept any sequence type as std::tuple or std::pair This is more Pythonic and compliments the std::vector and std::list casters which also accept sequences.
2016-11-27 19:32:04 +00:00
return load_impl(seq, convert, indices{});
nicer type_caster::load() calling conventions
2016-05-10 14:59:01 +00:00
}
quenched warnings on windows, comments in gil_scoped_release
2016-05-26 12:29:31 +00:00
Use rvalue subcasting when casting an rvalue container This updates the std::tuple, std::pair and `stl.h` type casters to forward their contained value according to whether the container being cast is an lvalue or rvalue reference. This fixes an issue where subcaster casts were always called with a const lvalue which meant nested type casters didn't have the desired `cast()` overload invoked. For example, this caused Eigen values in a tuple to end up with a readonly flag (issue #935) and made it impossible to return a container of move-only types (issue #853). This fixes both issues by adding templated universal reference `cast()` methods to the various container types that forward container elements according to the container reference type.
2017-07-03 23:12:09 +00:00
template <typename T>
static handle cast(T &&src, return_value_policy policy, handle parent) {
return cast_impl(std::forward<T>(src), policy, parent, indices{});
Adopt PEP 484 type hints for C++ types exported to Python
2016-08-03 23:40:40 +00:00
}
minor doc & style fixes
2016-09-06 04:02:29 +00:00
Simplify function signature annotation and parsing `type_descr` is now applied only to the final signature so that it only marks the argument types, but not nested types (e.g. for tuples) or return types.
2017-08-31 12:38:23 +00:00
static constexpr auto name = _("Tuple[") + concat(make_caster<Ts>::name...) + _("]");
generate more compact binaries
2015-07-26 14:33:49 +00:00
modularized logic in preceding change, fixed issue with char (fixes #150)
2016-03-26 22:04:10 +00:00
template <typename T> using cast_op_type = type;
Add movable cast support to type casters This commit allows type_casters to allow their local values to be moved away, rather than copied, when the type caster instance itself is an rvalue. This only applies (automatically) to type casters using PYBIND11_TYPE_CASTER; the generic type type casters don't own their own pointer, and various value casters (e.g. std::string, std::pair, arithmetic types) already cast to an rvalue (i.e. they return by value). This updates various calling code to attempt to get a movable value whenever the value is itself coming from a type caster about to be destroyed: for example, when constructing an std::pair or various stl.h containers. For types that don't support value moving, the cast_op falls back to an lvalue cast. There wasn't an obvious place to add the tests, so I added them to test_copy_move_policies, but also renamed it to drop the _policies as it now tests more than just policies.
2017-05-14 19:57:26 +00:00
operator type() & { return implicit_cast(indices{}); }
operator type() && { return std::move(*this).implicit_cast(indices{}); }
generate more compact binaries
2015-07-26 14:33:49 +00:00
Initial commit
2015-07-05 18:05:44 +00:00
protected:
Split up tuple caster and function argument loader This is needed in order to allow the tuple caster to accept any sequence while keeping the argument loader fast. There is also very little overlap between the two classes which makes the separation clean. It’s also good practice not to have completely new functionality in a specialization.
2016-11-27 17:19:34 +00:00
template <size_t... Is>
Use rvalue subcasting when casting an rvalue container This updates the std::tuple, std::pair and `stl.h` type casters to forward their contained value according to whether the container being cast is an lvalue or rvalue reference. This fixes an issue where subcaster casts were always called with a const lvalue which meant nested type casters didn't have the desired `cast()` overload invoked. For example, this caused Eigen values in a tuple to end up with a readonly flag (issue #935) and made it impossible to return a container of move-only types (issue #853). This fixes both issues by adding templated universal reference `cast()` methods to the various container types that forward container elements according to the container reference type.
2017-07-03 23:12:09 +00:00
type implicit_cast(index_sequence<Is...>) & { return type(cast_op<Ts>(std::get<Is>(subcasters))...); }
Add movable cast support to type casters This commit allows type_casters to allow their local values to be moved away, rather than copied, when the type caster instance itself is an rvalue. This only applies (automatically) to type casters using PYBIND11_TYPE_CASTER; the generic type type casters don't own their own pointer, and various value casters (e.g. std::string, std::pair, arithmetic types) already cast to an rvalue (i.e. they return by value). This updates various calling code to attempt to get a movable value whenever the value is itself coming from a type caster about to be destroyed: for example, when constructing an std::pair or various stl.h containers. For types that don't support value moving, the cast_op falls back to an lvalue cast. There wasn't an obvious place to add the tests, so I added them to test_copy_move_policies, but also renamed it to drop the _policies as it now tests more than just policies.
2017-05-14 19:57:26 +00:00
template <size_t... Is>
Use rvalue subcasting when casting an rvalue container This updates the std::tuple, std::pair and `stl.h` type casters to forward their contained value according to whether the container being cast is an lvalue or rvalue reference. This fixes an issue where subcaster casts were always called with a const lvalue which meant nested type casters didn't have the desired `cast()` overload invoked. For example, this caused Eigen values in a tuple to end up with a readonly flag (issue #935) and made it impossible to return a container of move-only types (issue #853). This fixes both issues by adding templated universal reference `cast()` methods to the various container types that forward container elements according to the container reference type.
2017-07-03 23:12:09 +00:00
type implicit_cast(index_sequence<Is...>) && { return type(cast_op<Ts>(std::move(std::get<Is>(subcasters)))...); }
Add movable cast support to type casters This commit allows type_casters to allow their local values to be moved away, rather than copied, when the type caster instance itself is an rvalue. This only applies (automatically) to type casters using PYBIND11_TYPE_CASTER; the generic type type casters don't own their own pointer, and various value casters (e.g. std::string, std::pair, arithmetic types) already cast to an rvalue (i.e. they return by value). This updates various calling code to attempt to get a movable value whenever the value is itself coming from a type caster about to be destroyed: for example, when constructing an std::pair or various stl.h containers. For types that don't support value moving, the cast_op falls back to an lvalue cast. There wasn't an obvious place to add the tests, so I added them to test_copy_move_policies, but also renamed it to drop the _policies as it now tests more than just policies.
2017-05-14 19:57:26 +00:00
Accept any sequence type as std::tuple or std::pair This is more Pythonic and compliments the std::vector and std::list casters which also accept sequences.
2016-11-27 19:32:04 +00:00
static constexpr bool load_impl(const sequence &, bool, index_sequence<>) { return true; }
Initial commit
2015-07-05 18:05:44 +00:00
Split up tuple caster and function argument loader This is needed in order to allow the tuple caster to accept any sequence while keeping the argument loader fast. There is also very little overlap between the two classes which makes the separation clean. It’s also good practice not to have completely new functionality in a specialization.
2016-11-27 17:19:34 +00:00
template <size_t... Is>
Accept any sequence type as std::tuple or std::pair This is more Pythonic and compliments the std::vector and std::list casters which also accept sequences.
2016-11-27 19:32:04 +00:00
bool load_impl(const sequence &seq, bool convert, index_sequence<Is...>) {
Add movable cast support to type casters This commit allows type_casters to allow their local values to be moved away, rather than copied, when the type caster instance itself is an rvalue. This only applies (automatically) to type casters using PYBIND11_TYPE_CASTER; the generic type type casters don't own their own pointer, and various value casters (e.g. std::string, std::pair, arithmetic types) already cast to an rvalue (i.e. they return by value). This updates various calling code to attempt to get a movable value whenever the value is itself coming from a type caster about to be destroyed: for example, when constructing an std::pair or various stl.h containers. For types that don't support value moving, the cast_op falls back to an lvalue cast. There wasn't an obvious place to add the tests, so I added them to test_copy_move_policies, but also renamed it to drop the _policies as it now tests more than just policies.
2017-05-14 19:57:26 +00:00
for (bool r : {std::get<Is>(subcasters).load(seq[Is], convert)...})
Initial commit
2015-07-05 18:05:44 +00:00
if (!r)
return false;
return true;
}
/* Implementation: Convert a C++ tuple into a Python tuple */
Use rvalue subcasting when casting an rvalue container This updates the std::tuple, std::pair and `stl.h` type casters to forward their contained value according to whether the container being cast is an lvalue or rvalue reference. This fixes an issue where subcaster casts were always called with a const lvalue which meant nested type casters didn't have the desired `cast()` overload invoked. For example, this caused Eigen values in a tuple to end up with a readonly flag (issue #935) and made it impossible to return a container of move-only types (issue #853). This fixes both issues by adding templated universal reference `cast()` methods to the various container types that forward container elements according to the container reference type.
2017-07-03 23:12:09 +00:00
template <typename T, size_t... Is>
static handle cast_impl(T &&src, return_value_policy policy, handle parent, index_sequence<Is...>) {
std::array<object, size> entries{{
reinterpret_steal<object>(make_caster<Ts>::cast(std::get<Is>(std::forward<T>(src)), policy, parent))...
Initial commit
2015-07-05 18:05:44 +00:00
}};
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
for (const auto &entry: entries)
if (!entry)
return handle();
tuple result(size);
Use object class to hold partially converted python objects. Using object class to hold converted object automatically deallocates object if an exception is thrown or scope is left before constructing complete Python object. Additionally added method object::release() that allows to release ownership of python object without decreasing its reference count.
2015-12-30 20:03:57 +00:00
int counter = 0;
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
for (auto & entry: entries)
PyTuple_SET_ITEM(result.ptr(), counter++, entry.release().ptr());
return result.release();
Initial commit
2015-07-05 18:05:44 +00:00
}
Use rvalue subcasting when casting an rvalue container This updates the std::tuple, std::pair and `stl.h` type casters to forward their contained value according to whether the container being cast is an lvalue or rvalue reference. This fixes an issue where subcaster casts were always called with a const lvalue which meant nested type casters didn't have the desired `cast()` overload invoked. For example, this caused Eigen values in a tuple to end up with a readonly flag (issue #935) and made it impossible to return a container of move-only types (issue #853). This fixes both issues by adding templated universal reference `cast()` methods to the various container types that forward container elements according to the container reference type.
2017-07-03 23:12:09 +00:00
Tuple<make_caster<Ts>...> subcasters;
Initial commit
2015-07-05 18:05:44 +00:00
};
Combine std::tuple/std::pair logic The std::pair caster can be written as a special case of the std::tuple caster; this combines them via a base `tuple_caster` class (which is essentially identical to the previous std::tuple caster). This also removes the special empty tuple base case: returning an empty tuple is relatively rare, and the base case still works perfectly well even when the tuple types is an empty list.
2017-07-04 18:57:41 +00:00
template <typename T1, typename T2> class type_caster<std::pair<T1, T2>>
: public tuple_caster<std::pair, T1, T2> {};
Use rvalue subcasting when casting an rvalue container This updates the std::tuple, std::pair and `stl.h` type casters to forward their contained value according to whether the container being cast is an lvalue or rvalue reference. This fixes an issue where subcaster casts were always called with a const lvalue which meant nested type casters didn't have the desired `cast()` overload invoked. For example, this caused Eigen values in a tuple to end up with a readonly flag (issue #935) and made it impossible to return a container of move-only types (issue #853). This fixes both issues by adding templated universal reference `cast()` methods to the various container types that forward container elements according to the container reference type.
2017-07-03 23:12:09 +00:00
template <typename... Ts> class type_caster<std::tuple<Ts...>>
: public tuple_caster<std::tuple, Ts...> {};
Combine std::tuple/std::pair logic The std::pair caster can be written as a special case of the std::tuple caster; this combines them via a base `tuple_caster` class (which is essentially identical to the previous std::tuple caster). This also removes the special empty tuple base case: returning an empty tuple is relatively rare, and the base case still works perfectly well even when the tuple types is an empty list.
2017-07-04 18:57:41 +00:00
Improve custom holder support (#607) * Abstract away some holder functionality (resolve #585) Custom holder types which don't have `.get()` can select the correct function to call by specializing `holder_traits`. * Add support for move-only holders (fix #605)
2017-01-31 16:05:44 +00:00
/// Helper class which abstracts away certain actions. Users can provide specializations for
/// custom holders, but it's only necessary if the type has a non-standard interface.
template <typename T>
struct holder_helper {
static auto get(const T &p) -> decltype(p.get()) { return p.get(); }
};
Initial commit
2015-07-05 18:05:44 +00:00
/// Type caster for holder types like std::shared_ptr, etc.
Improve custom holder support (#607) * Abstract away some holder functionality (resolve #585) Custom holder types which don't have `.get()` can select the correct function to call by specializing `holder_traits`. * Add support for move-only holders (fix #605)
2017-01-31 16:05:44 +00:00
template <typename type, typename holder_type>
struct copyable_holder_caster : public type_caster_base<type> {
Initial commit
2015-07-05 18:05:44 +00:00
public:
Multiple inheritance support
2016-09-11 11:00:40 +00:00
using base = type_caster_base<type>;
Add static_assert to holder casters The holder casters assume but don't check that a `holder<type>`'s `type` is really a `type_caster_base<type>`; this adds a static_assert to make sure this is really the case, to turn things like `std::shared_ptr<array>` into a compilation failure. Fixes #785
2017-04-07 15:11:14 +00:00
static_assert(std::is_base_of<base, type_caster<type>>::value,
"Holder classes are only supported for custom types");
Multiple inheritance support
2016-09-11 11:00:40 +00:00
using base::base;
using base::cast;
using base::typeinfo;
using base::value;
improved shared pointer support (fixes #14)
2015-11-24 22:05:58 +00:00
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
bool load(handle src, bool convert) {
return base::template load_impl<copyable_holder_caster<type, holder_type>>(src, convert);
Multiple inheritance support
2016-09-11 11:00:40 +00:00
}
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
explicit operator type*() { return this->value; }
explicit operator type&() { return *(this->value); }
Use std::addressof to obtain holder address instead of operator&
2018-06-20 15:33:50 +00:00
explicit operator holder_type*() { return std::addressof(holder); }
Multiple inheritance support
2016-09-11 11:00:40 +00:00
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
// Workaround for Intel compiler bug
// see pybind11 issue 94
#if defined(__ICC) || defined(__INTEL_COMPILER)
operator holder_type&() { return holder; }
#else
explicit operator holder_type&() { return holder; }
#endif
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
static handle cast(const holder_type &src, return_value_policy, handle) {
const auto *ptr = holder_helper<holder_type>::get(src);
return type_caster_base<type>::cast_holder(ptr, &src);
}
Multiple inheritance support
2016-09-11 11:00:40 +00:00
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
protected:
friend class type_caster_generic;
void check_holder_compat() {
if (typeinfo->default_holder)
throw cast_error("Unable to load a custom holder type from a default-holder instance");
Multiple inheritance support
2016-09-11 11:00:40 +00:00
}
Allow binding factory functions as constructors This allows you to use: cls.def(py::init(&factory_function)); where `factory_function` returns a pointer, holder, or value of the class type (or a derived type). Various compile-time checks (static_asserts) are performed to ensure the function is valid, and various run-time type checks where necessary. Some other details of this feature: - The `py::init` name doesn't conflict with the templated no-argument `py::init<...>()`, but keeps the naming consistent: the existing templated, no-argument one wraps constructors, the no-template, function-argument one wraps factory functions. - If returning a CppClass (whether by value or pointer) when an CppAlias is required (i.e. python-side inheritance and a declared alias), a dynamic_cast to the alias is attempted (for the pointer version); if it fails, or if returned by value, an Alias(Class &&) constructor is invoked. If this constructor doesn't exist, a runtime error occurs. - for holder returns when an alias is required, we try a dynamic_cast of the wrapped pointer to the alias to see if it is already an alias instance; if it isn't, we raise an error. - `py::init(class_factory, alias_factory)` is also available that takes two factories: the first is called when an alias is not needed, the second when it is. - Reimplement factory instance clearing. The previous implementation failed under python-side multiple inheritance: *each* inherited type's factory init would clear the instance instead of only setting its own type value. The new implementation here clears just the relevant value pointer. - dealloc is updated to explicitly set the leftover value pointer to nullptr and the `holder_constructed` flag to false so that it can be used to clear preallocated value without needing to rebuild the instance internals data. - Added various tests to test out new allocation/deallocation code. - With preallocation now done lazily, init factory holders can completely avoid the extra overhead of needing an extra allocation/deallocation. - Updated documentation to make factory constructors the default advanced constructor style. - If an `__init__` is called a second time, we have two choices: we can throw away the first instance, replacing it with the second; or we can ignore the second call. The latter is slightly easier, so do that.
2017-06-13 01:52:48 +00:00
bool load_value(value_and_holder &&v_h) {
Support multiple inheritance from python This commit allows multiple inheritance of pybind11 classes from Python, e.g. class MyType(Base1, Base2): def __init__(self): Base1.__init__(self) Base2.__init__(self) where Base1 and Base2 are pybind11-exported classes. This requires collapsing the various builtin base objects (pybind11_object_56, ...) introduced in 2.1 into a single pybind11_object of a fixed size; this fixed size object allocates enough space to contain either a simple object (one base class & small* holder instance), or a pointer to a new allocation that can contain an arbitrary number of base classes and holders, with holder size unrestricted. * "small" here means having a sizeof() of at most 2 pointers, which is enough to fit unique_ptr (sizeof is 1 ptr) and shared_ptr (sizeof is 2 ptrs). To minimize the performance impact, this repurposes `internals::registered_types_py` to store a vector of pybind-registered base types. For direct-use pybind types (e.g. the `PyA` for a C++ `A`) this is simply storing the same thing as before, but now in a vector; for Python-side inherited types, the map lets us avoid having to do a base class traversal as long as we've seen the class before. The change to vector is needed for multiple inheritance: Python types inheriting from multiple registered bases have one entry per base.
2017-02-23 02:36:09 +00:00
if (v_h.holder_constructed()) {
value = v_h.value_ptr();
Build /permissive- under VS2017 Building with the (VS2017) /permissive- flag puts the compiler into stricter standards-compliant mode. It shouldn't cause the compiler to work differently--it just disallows some non-conforming code--so should be perfectly fine for the test suite under all VS2017 builds. This commit also fixes one failure under non-permissive mode.
2017-10-22 15:06:52 +00:00
holder = v_h.template holder<holder_type>();
Allow references to objects held by smart pointers (#533)
2016-12-07 01:36:44 +00:00
return true;
} else {
throw cast_error("Unable to cast from non-held to held instance (T& to Holder<T>) "
#if defined(NDEBUG)
"(compile in debug mode for type information)");
#else
"of type '" + type_id<holder_type>() + "''");
#endif
}
}
Multiple inheritance support
2016-09-11 11:00:40 +00:00
template <typename T = holder_type, detail::enable_if_t<!std::is_constructible<T, const T &, type*>::value, int> = 0>
bool try_implicit_casts(handle, bool) { return false; }
template <typename T = holder_type, detail::enable_if_t<std::is_constructible<T, const T &, type*>::value, int> = 0>
bool try_implicit_casts(handle src, bool convert) {
for (auto &cast : typeinfo->implicit_casts) {
Improve custom holder support (#607) * Abstract away some holder functionality (resolve #585) Custom holder types which don't have `.get()` can select the correct function to call by specializing `holder_traits`. * Add support for move-only holders (fix #605)
2017-01-31 16:05:44 +00:00
copyable_holder_caster sub_caster(*cast.first);
Multiple inheritance support
2016-09-11 11:00:40 +00:00
if (sub_caster.load(src, convert)) {
value = cast.second(sub_caster.value);
holder = holder_type(sub_caster.holder, (type *) value);
return true;
}
}
improved handling of shared/smart pointers Previously, pybind11 required classes using std::shared_ptr<> to derive from std::enable_shared_from_this<> (or compilation failures would ensue). Everything now also works for classes that don't do this, assuming that some basic rules are followed (e.g. never passing "raw" pointers of instances manged by shared pointers). The safer std::enable_shared_from_this<> approach continues to be supported.
2016-01-17 21:36:40 +00:00
return false;
Initial commit
2015-07-05 18:05:44 +00:00
}
improved shared pointer support (fixes #14)
2015-11-24 22:05:58 +00:00
Fix compilation with Intel's compiler ICC was reporting that `try_direct_conversions()` cannot be `constexpr` because `handle` is not a literal type. The fix removes `constexpr` from the function since it isn't strictly needed. This commit also suppresses new false positive warnings which mostly appear in constexpr contexts (where the compiler knows conversions are safe).
2017-07-03 23:27:18 +00:00
static bool try_direct_conversions(handle) { return false; }
Fixes for compilation/segfault problems with Intel (issue 94)
2016-02-18 17:38:27 +00:00
fix for std::shared_ptr proposed by Vayu (fixes #8)
2015-11-12 22:27:20 +00:00
Initial commit
2015-07-05 18:05:44 +00:00
holder_type holder;
};
Support std::shared_ptr holder type out of the box With this there is no more need for manual user declarations like `PYBIND11_DECLARE_HOLDER_TYPE(T, std::shared_ptr<T>)`. Existing ones will still compile without error -- they will just be ignored silently. Resolves #446.
2016-10-18 11:56:33 +00:00
/// Specialize for the common std::shared_ptr, so users don't need to
template <typename T>
Improve custom holder support (#607) * Abstract away some holder functionality (resolve #585) Custom holder types which don't have `.get()` can select the correct function to call by specializing `holder_traits`. * Add support for move-only holders (fix #605)
2017-01-31 16:05:44 +00:00
class type_caster<std::shared_ptr<T>> : public copyable_holder_caster<T, std::shared_ptr<T>> { };
template <typename type, typename holder_type>
struct move_only_holder_caster {
Add static_assert to holder casters The holder casters assume but don't check that a `holder<type>`'s `type` is really a `type_caster_base<type>`; this adds a static_assert to make sure this is really the case, to turn things like `std::shared_ptr<array>` into a compilation failure. Fixes #785
2017-04-07 15:11:14 +00:00
static_assert(std::is_base_of<type_caster_base<type>, type_caster<type>>::value,
"Holder classes are only supported for custom types");
Improve custom holder support (#607) * Abstract away some holder functionality (resolve #585) Custom holder types which don't have `.get()` can select the correct function to call by specializing `holder_traits`. * Add support for move-only holders (fix #605)
2017-01-31 16:05:44 +00:00
static handle cast(holder_type &&src, return_value_policy, handle) {
auto *ptr = holder_helper<holder_type>::get(src);
Use std::addressof to obtain holder address instead of operator&
2018-06-20 15:33:50 +00:00
return type_caster_base<type>::cast_holder(ptr, std::addressof(src));
Improve custom holder support (#607) * Abstract away some holder functionality (resolve #585) Custom holder types which don't have `.get()` can select the correct function to call by specializing `holder_traits`. * Add support for move-only holders (fix #605)
2017-01-31 16:05:44 +00:00
}
Make it possible to generate constexpr signatures in C++11 mode The current C++14 constexpr signatures don't require relaxed constexpr, but only `auto` return type deduction. To get around this in C++11, the type caster's `name()` static member functions are turned into `static constexpr auto` variables.
2017-07-02 09:48:56 +00:00
static constexpr auto name = type_caster_base<type>::name;
Improve custom holder support (#607) * Abstract away some holder functionality (resolve #585) Custom holder types which don't have `.get()` can select the correct function to call by specializing `holder_traits`. * Add support for move-only holders (fix #605)
2017-01-31 16:05:44 +00:00
};
template <typename type, typename deleter>
class type_caster<std::unique_ptr<type, deleter>>
: public move_only_holder_caster<type, std::unique_ptr<type, deleter>> { };
template <typename type, typename holder_type>
Detect std::pair non-copyability Pre-C++17, std::pair can technically have an copy constructor even though it can't actually be invoked without a compilation failure (due to the underlying types being non-copyable). Most stls, including libc++ since ~3.4, use the C++17 behaviour of not exposing an uncallable copy constructor, but FreeBSD deliberately broke their libc++ to preserve the nonsensical behaviour (https://svnweb.freebsd.org/base?view=revision&revision=261801). This updates pybind's internal `is_copy_constructible` to also detect the std::pair case under pre-C++17. This also everything (except for a couple cases in the internal version) to use the internal `is_copy_constructible` rather than `std::is_copy_constructible`.
2017-07-27 18:55:17 +00:00
using type_caster_holder = conditional_t<is_copy_constructible<holder_type>::value,
Improve custom holder support (#607) * Abstract away some holder functionality (resolve #585) Custom holder types which don't have `.get()` can select the correct function to call by specializing `holder_traits`. * Add support for move-only holders (fix #605)
2017-01-31 16:05:44 +00:00
copyable_holder_caster<type, holder_type>,
move_only_holder_caster<type, holder_type>>;
Support std::shared_ptr holder type out of the box With this there is no more need for manual user declarations like `PYBIND11_DECLARE_HOLDER_TYPE(T, std::shared_ptr<T>)`. Existing ones will still compile without error -- they will just be ignored silently. Resolves #446.
2016-10-18 11:56:33 +00:00
always_construct_holder feature to support intrusively reference-counted types (#561) * always_construct_holder feature to support intrusively reference-counted types * added testcase
2016-12-15 22:44:23 +00:00
template <typename T, bool Value = false> struct always_construct_holder { static constexpr bool value = Value; };
Support std::shared_ptr holder type out of the box With this there is no more need for manual user declarations like `PYBIND11_DECLARE_HOLDER_TYPE(T, std::shared_ptr<T>)`. Existing ones will still compile without error -- they will just be ignored silently. Resolves #446.
2016-10-18 11:56:33 +00:00
/// Create a specialization for custom holder types (silently ignores std::shared_ptr)
always_construct_holder feature to support intrusively reference-counted types (#561) * always_construct_holder feature to support intrusively reference-counted types * added testcase
2016-12-15 22:44:23 +00:00
#define PYBIND11_DECLARE_HOLDER_TYPE(type, holder_type, ...) \
Support std::shared_ptr holder type out of the box With this there is no more need for manual user declarations like `PYBIND11_DECLARE_HOLDER_TYPE(T, std::shared_ptr<T>)`. Existing ones will still compile without error -- they will just be ignored silently. Resolves #446.
2016-10-18 11:56:33 +00:00
namespace pybind11 { namespace detail { \
template <typename type> \
always_construct_holder feature to support intrusively reference-counted types (#561) * always_construct_holder feature to support intrusively reference-counted types * added testcase
2016-12-15 22:44:23 +00:00
struct always_construct_holder<holder_type> : always_construct_holder<void, ##__VA_ARGS__> { }; \
template <typename type> \
Support std::shared_ptr holder type out of the box With this there is no more need for manual user declarations like `PYBIND11_DECLARE_HOLDER_TYPE(T, std::shared_ptr<T>)`. Existing ones will still compile without error -- they will just be ignored silently. Resolves #446.
2016-10-18 11:56:33 +00:00
class type_caster<holder_type, enable_if_t<!is_shared_ptr<holder_type>::value>> \
: public type_caster_holder<type, holder_type> { }; \
}}
Allow passing base types as a template parameter This allows a slightly cleaner base type specification of: py::class_<Type, Base>("Type") as an alternative to py::class_<Type>("Type", py::base<Base>()) As with the other template parameters, the order relative to the holder or trampoline types doesn't matter. This also includes a compile-time assertion failure if attempting to specify more than one base class (but is easily extendible to support multiple inheritance, someday, by updating the class_selector::set_bases function to set multiple bases).
2016-09-06 16:27:00 +00:00
// PYBIND11_DECLARE_HOLDER_TYPE holder types:
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
template <typename base, typename holder> struct is_holder_type :
Allow passing base types as a template parameter This allows a slightly cleaner base type specification of: py::class_<Type, Base>("Type") as an alternative to py::class_<Type>("Type", py::base<Base>()) As with the other template parameters, the order relative to the holder or trampoline types doesn't matter. This also includes a compile-time assertion failure if attempting to specify more than one base class (but is easily extendible to support multiple inheritance, someday, by updating the class_selector::set_bases function to set multiple bases).
2016-09-06 16:27:00 +00:00
std::is_base_of<detail::type_caster_holder<base, holder>, detail::type_caster<holder>> {};
// Specialization for always-supported unique_ptr holders:
template <typename base, typename deleter> struct is_holder_type<base, std::unique_ptr<base, deleter>> :
std::true_type {};
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
Make it possible to generate constexpr signatures in C++11 mode The current C++14 constexpr signatures don't require relaxed constexpr, but only `auto` return type deduction. To get around this in C++11, the type caster's `name()` static member functions are turned into `static constexpr auto` variables.
2017-07-02 09:48:56 +00:00
template <typename T> struct handle_type_name { static constexpr auto name = _<T>(); };
template <> struct handle_type_name<bytes> { static constexpr auto name = _(PYBIND11_BYTES_NAME); };
template <> struct handle_type_name<args> { static constexpr auto name = _("*args"); };
template <> struct handle_type_name<kwargs> { static constexpr auto name = _("**kwargs"); };
improved signature names for subclasses of pybind11::handle
2016-01-17 21:36:38 +00:00
considerable simplifications to the Python type casters
2015-12-16 11:11:01 +00:00
template <typename type>
Add py::isinstance<T>(obj) for generalized Python type checking Allows checking the Python types before creating an object instead of after. For example: ```c++ auto l = list(ptr, true); if (l.check()) // ... ``` The above is replaced with: ```c++ if (isinstance<list>(ptr)) { auto l = reinterpret_borrow(ptr); // ... } ``` This deprecates `py::object::check()`. `py::isinstance()` covers the same use case, but it can also check for user-defined types: ```c++ class Pet { ... }; py::class_<Pet>(...); m.def("is_pet", [](py::object obj) { return py::isinstance<Pet>(obj); // works as expected }); ```
2016-10-23 12:50:08 +00:00
struct pyobject_caster {
template <typename T = type, enable_if_t<std::is_same<T, handle>::value, int> = 0>
bool load(handle src, bool /* convert */) { value = src; return static_cast<bool>(value); }
considerable simplifications to the Python type casters
2015-12-16 11:11:01 +00:00
use detail::enable_if_t everywhere
2016-09-12 15:36:43 +00:00
template <typename T = type, enable_if_t<std::is_base_of<object, T>::value, int> = 0>
Add py::isinstance<T>(obj) for generalized Python type checking Allows checking the Python types before creating an object instead of after. For example: ```c++ auto l = list(ptr, true); if (l.check()) // ... ``` The above is replaced with: ```c++ if (isinstance<list>(ptr)) { auto l = reinterpret_borrow(ptr); // ... } ``` This deprecates `py::object::check()`. `py::isinstance()` covers the same use case, but it can also check for user-defined types: ```c++ class Pet { ... }; py::class_<Pet>(...); m.def("is_pet", [](py::object obj) { return py::isinstance<Pet>(obj); // works as expected }); ```
2016-10-23 12:50:08 +00:00
bool load(handle src, bool /* convert */) {
if (!isinstance<type>(src))
return false;
Add py::reinterpret_borrow<T>()/steal<T>() for low-level unchecked casts The pytype converting constructors are convenient and safe for user code, but for library internals the additional type checks and possible conversions are sometimes not desired. `reinterpret_borrow<T>()` and `reinterpret_steal<T>()` serve as the low-level unsafe counterparts of `cast<T>()`. This deprecates the `object(handle, bool)` constructor. Renamed `borrowed` parameter to `is_borrowed` to avoid shadowing warnings on MSVC.
2016-10-28 01:08:15 +00:00
value = reinterpret_borrow<type>(src);
Add py::isinstance<T>(obj) for generalized Python type checking Allows checking the Python types before creating an object instead of after. For example: ```c++ auto l = list(ptr, true); if (l.check()) // ... ``` The above is replaced with: ```c++ if (isinstance<list>(ptr)) { auto l = reinterpret_borrow(ptr); // ... } ``` This deprecates `py::object::check()`. `py::isinstance()` covers the same use case, but it can also check for user-defined types: ```c++ class Pet { ... }; py::class_<Pet>(...); m.def("is_pet", [](py::object obj) { return py::isinstance<Pet>(obj); // works as expected }); ```
2016-10-23 12:50:08 +00:00
return true;
}
considerable simplifications to the Python type casters
2015-12-16 11:11:01 +00:00
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
static handle cast(const handle &src, return_value_policy /* policy */, handle /* parent */) {
return src.inc_ref();
Initial commit
2015-07-05 18:05:44 +00:00
}
Make it possible to generate constexpr signatures in C++11 mode The current C++14 constexpr signatures don't require relaxed constexpr, but only `auto` return type deduction. To get around this in C++11, the type caster's `name()` static member functions are turned into `static constexpr auto` variables.
2017-07-02 09:48:56 +00:00
PYBIND11_TYPE_CASTER(type, handle_type_name<type>::name);
Initial commit
2015-07-05 18:05:44 +00:00
};
Add py::isinstance<T>(obj) for generalized Python type checking Allows checking the Python types before creating an object instead of after. For example: ```c++ auto l = list(ptr, true); if (l.check()) // ... ``` The above is replaced with: ```c++ if (isinstance<list>(ptr)) { auto l = reinterpret_borrow(ptr); // ... } ``` This deprecates `py::object::check()`. `py::isinstance()` covers the same use case, but it can also check for user-defined types: ```c++ class Pet { ... }; py::class_<Pet>(...); m.def("is_pet", [](py::object obj) { return py::isinstance<Pet>(obj); // works as expected }); ```
2016-10-23 12:50:08 +00:00
template <typename T>
class type_caster<T, enable_if_t<is_pyobject<T>::value>> : public pyobject_caster<T> { };
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
// Our conditions for enabling moving are quite restrictive:
// At compile time:
// - T needs to be a non-const, non-pointer, non-reference type
// - type_caster<T>::operator T&() must exist
// - the type must be move constructible (obviously)
// At run-time:
// - if the type is non-copy-constructible, the object must be the sole owner of the type (i.e. it
// must have ref_count() == 1)h
// If any of the above are not satisfied, we fall back to copying.
Numpy: better compilation errors, long double support (#619) * Clarify PYBIND11_NUMPY_DTYPE documentation The current documentation and example reads as though PYBIND11_NUMPY_DTYPE is a declarative macro along the same lines as PYBIND11_DECLARE_HOLDER_TYPE, but it isn't. The changes the documentation and docs example to make it clear that you need to "call" the macro. * Add satisfies_{all,any,none}_of<T, Preds> `satisfies_all_of<T, Pred1, Pred2, Pred3>` is a nice legibility-enhanced shortcut for `is_all<Pred1<T>, Pred2<T>, Pred3<T>>`. * Give better error message for non-POD dtype attempts If you try to use a non-POD data type, you get difficult-to-interpret compilation errors (about ::name() not being a member of an internal pybind11 struct, among others), for which isn't at all obvious what the problem is. This adds a static_assert for such cases. It also changes the base case from an empty struct to the is_pod_struct case by no longer using `enable_if<is_pod_struct>` but instead using a static_assert: thus specializations avoid the base class, POD types work, and non-POD types (and unimplemented POD types like std::array) get a more informative static_assert failure. * Prefix macros with PYBIND11_ numpy.h uses unprefixed macros, which seems undesirable. This prefixes them with PYBIND11_ to match all the other macros in numpy.h (and elsewhere). * Add long double support This adds long double and std::complex<long double> support for numpy arrays. This allows some simplification of the code used to generate format descriptors; the new code uses fewer macros, instead putting the code as different templated options; the template conditions end up simpler with this because we are now supporting all basic C++ arithmetic types (and so can use is_arithmetic instead of is_integral + multiple different specializations). In addition to testing that it is indeed working in the test script, it also adds various offset and size calculations there, which fixes the test failures under x86 compilations.
2017-01-31 16:00:15 +00:00
template <typename T> using move_is_plain_type = satisfies_none_of<T,
std::is_void, std::is_pointer, std::is_reference, std::is_const
Change all_of_t/any_of_t to all_of/any_of, add none_of This replaces the current `all_of_t<Pred, Ts...>` with `all_of<Ts...>`, with previous use of `all_of_t<Pred, Ts...>` becoming `all_of<Pred<Ts>...>` (and similarly for `any_of_t`). It also adds a `none_of<Ts...>`, a shortcut for `negation<any_of<Ts...>>`. This allows `all_of` and `any_of` to be used a bit more flexible, e.g. in cases where several predicates need to be tested for the same type instead of the same predicate for multiple types. This commit replaces the implementation with a more efficient version for non-MSVC. For MSVC, this changes the workaround to use the built-in, recursive std::conjunction/std::disjunction instead. This also removes the `count_t` since `any_of_t` and `all_of_t` were the only things using it. This commit also rearranges some of the future std imports to use actual `std` implementations for C++14/17 features when under the appropriate compiler mode, as we were already doing for a few things (like index_sequence). Most of these aren't saving much (the implementation for enable_if_t, for example, is trivial), but I think it makes the intention of the code instantly clear. It also enables MSVC's native std::index_sequence support.
2016-12-12 23:11:49 +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
template <typename T, typename SFINAE = void> struct move_always : std::false_type {};
Change all_of_t/any_of_t to all_of/any_of, add none_of This replaces the current `all_of_t<Pred, Ts...>` with `all_of<Ts...>`, with previous use of `all_of_t<Pred, Ts...>` becoming `all_of<Pred<Ts>...>` (and similarly for `any_of_t`). It also adds a `none_of<Ts...>`, a shortcut for `negation<any_of<Ts...>>`. This allows `all_of` and `any_of` to be used a bit more flexible, e.g. in cases where several predicates need to be tested for the same type instead of the same predicate for multiple types. This commit replaces the implementation with a more efficient version for non-MSVC. For MSVC, this changes the workaround to use the built-in, recursive std::conjunction/std::disjunction instead. This also removes the `count_t` since `any_of_t` and `all_of_t` were the only things using it. This commit also rearranges some of the future std imports to use actual `std` implementations for C++14/17 features when under the appropriate compiler mode, as we were already doing for a few things (like index_sequence). Most of these aren't saving much (the implementation for enable_if_t, for example, is trivial), but I think it makes the intention of the code instantly clear. It also enables MSVC's native std::index_sequence support.
2016-12-12 23:11:49 +00:00
template <typename T> struct move_always<T, enable_if_t<all_of<
move_is_plain_type<T>,
Detect std::pair non-copyability Pre-C++17, std::pair can technically have an copy constructor even though it can't actually be invoked without a compilation failure (due to the underlying types being non-copyable). Most stls, including libc++ since ~3.4, use the C++17 behaviour of not exposing an uncallable copy constructor, but FreeBSD deliberately broke their libc++ to preserve the nonsensical behaviour (https://svnweb.freebsd.org/base?view=revision&revision=261801). This updates pybind's internal `is_copy_constructible` to also detect the std::pair case under pre-C++17. This also everything (except for a couple cases in the internal version) to use the internal `is_copy_constructible` rather than `std::is_copy_constructible`.
2017-07-27 18:55:17 +00:00
negation<is_copy_constructible<T>>,
Change all_of_t/any_of_t to all_of/any_of, add none_of This replaces the current `all_of_t<Pred, Ts...>` with `all_of<Ts...>`, with previous use of `all_of_t<Pred, Ts...>` becoming `all_of<Pred<Ts>...>` (and similarly for `any_of_t`). It also adds a `none_of<Ts...>`, a shortcut for `negation<any_of<Ts...>>`. This allows `all_of` and `any_of` to be used a bit more flexible, e.g. in cases where several predicates need to be tested for the same type instead of the same predicate for multiple types. This commit replaces the implementation with a more efficient version for non-MSVC. For MSVC, this changes the workaround to use the built-in, recursive std::conjunction/std::disjunction instead. This also removes the `count_t` since `any_of_t` and `all_of_t` were the only things using it. This commit also rearranges some of the future std imports to use actual `std` implementations for C++14/17 features when under the appropriate compiler mode, as we were already doing for a few things (like index_sequence). Most of these aren't saving much (the implementation for enable_if_t, for example, is trivial), but I think it makes the intention of the code instantly clear. It also enables MSVC's native std::index_sequence support.
2016-12-12 23:11:49 +00:00
std::is_move_constructible<T>,
Fix pointer to reference error in type_caster on MSVC (#583)
2017-01-03 10:52:05 +00:00
std::is_same<decltype(std::declval<make_caster<T>>().operator T&()), T&>
Change all_of_t/any_of_t to all_of/any_of, add none_of This replaces the current `all_of_t<Pred, Ts...>` with `all_of<Ts...>`, with previous use of `all_of_t<Pred, Ts...>` becoming `all_of<Pred<Ts>...>` (and similarly for `any_of_t`). It also adds a `none_of<Ts...>`, a shortcut for `negation<any_of<Ts...>>`. This allows `all_of` and `any_of` to be used a bit more flexible, e.g. in cases where several predicates need to be tested for the same type instead of the same predicate for multiple types. This commit replaces the implementation with a more efficient version for non-MSVC. For MSVC, this changes the workaround to use the built-in, recursive std::conjunction/std::disjunction instead. This also removes the `count_t` since `any_of_t` and `all_of_t` were the only things using it. This commit also rearranges some of the future std imports to use actual `std` implementations for C++14/17 features when under the appropriate compiler mode, as we were already doing for a few things (like index_sequence). Most of these aren't saving much (the implementation for enable_if_t, for example, is trivial), but I think it makes the intention of the code instantly clear. It also enables MSVC's native std::index_sequence support.
2016-12-12 23:11:49 +00:00
>::value>> : std::true_type {};
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
template <typename T, typename SFINAE = void> struct move_if_unreferenced : std::false_type {};
Change all_of_t/any_of_t to all_of/any_of, add none_of This replaces the current `all_of_t<Pred, Ts...>` with `all_of<Ts...>`, with previous use of `all_of_t<Pred, Ts...>` becoming `all_of<Pred<Ts>...>` (and similarly for `any_of_t`). It also adds a `none_of<Ts...>`, a shortcut for `negation<any_of<Ts...>>`. This allows `all_of` and `any_of` to be used a bit more flexible, e.g. in cases where several predicates need to be tested for the same type instead of the same predicate for multiple types. This commit replaces the implementation with a more efficient version for non-MSVC. For MSVC, this changes the workaround to use the built-in, recursive std::conjunction/std::disjunction instead. This also removes the `count_t` since `any_of_t` and `all_of_t` were the only things using it. This commit also rearranges some of the future std imports to use actual `std` implementations for C++14/17 features when under the appropriate compiler mode, as we were already doing for a few things (like index_sequence). Most of these aren't saving much (the implementation for enable_if_t, for example, is trivial), but I think it makes the intention of the code instantly clear. It also enables MSVC's native std::index_sequence support.
2016-12-12 23:11:49 +00:00
template <typename T> struct move_if_unreferenced<T, enable_if_t<all_of<
move_is_plain_type<T>,
negation<move_always<T>>,
std::is_move_constructible<T>,
Fix pointer to reference error in type_caster on MSVC (#583)
2017-01-03 10:52:05 +00:00
std::is_same<decltype(std::declval<make_caster<T>>().operator T&()), T&>
Change all_of_t/any_of_t to all_of/any_of, add none_of This replaces the current `all_of_t<Pred, Ts...>` with `all_of<Ts...>`, with previous use of `all_of_t<Pred, Ts...>` becoming `all_of<Pred<Ts>...>` (and similarly for `any_of_t`). It also adds a `none_of<Ts...>`, a shortcut for `negation<any_of<Ts...>>`. This allows `all_of` and `any_of` to be used a bit more flexible, e.g. in cases where several predicates need to be tested for the same type instead of the same predicate for multiple types. This commit replaces the implementation with a more efficient version for non-MSVC. For MSVC, this changes the workaround to use the built-in, recursive std::conjunction/std::disjunction instead. This also removes the `count_t` since `any_of_t` and `all_of_t` were the only things using it. This commit also rearranges some of the future std imports to use actual `std` implementations for C++14/17 features when under the appropriate compiler mode, as we were already doing for a few things (like index_sequence). Most of these aren't saving much (the implementation for enable_if_t, for example, is trivial), but I think it makes the intention of the code instantly clear. It also enables MSVC's native std::index_sequence support.
2016-12-12 23:11:49 +00:00
>::value>> : std::true_type {};
template <typename T> using move_never = none_of<move_always<T>, move_if_unreferenced<T>>;
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
Fail static_assert when trying to reference non-referencable types The previous commit to address #392 triggers a compiler warning about returning a reference to a local variable, which is *not* a false alarm: the following: py::cast<int &>(o) (which happens internally in an overload declaration) really is returning a reference to a local, because the cast operators for the type_caster for numeric types returns a reference to its own member. This commit adds a static_assert to make that a compilation failure rather than returning a reference into about-to-be-freed memory. Incidentally, this is also a fix for #219, which is exactly the same issue: we can't reference numeric primitives that are cast from wrappers around python numeric types.
2016-09-07 17:38:32 +00:00
// Detect whether returning a `type` from a cast on type's type_caster is going to result in a
// reference or pointer to a local variable of the type_caster. Basically, only
// non-reference/pointer `type`s and reference/pointers from a type_caster_generic are safe;
// everything else returns a reference/pointer to a local variable.
template <typename type> using cast_is_temporary_value_reference = bool_constant<
(std::is_reference<type>::value || std::is_pointer<type>::value) &&
!std::is_base_of<type_caster_generic, make_caster<type>>::value
>;
Add an ability to avoid forcing rvp::move Eigen::Ref objects, when returned, are almost always returned as rvalues; what's important is the data they reference, not the outer shell, and so we want to be able to use `::copy`, `::reference_internal`, etc. to refer to the data the Eigen::Ref references (in the following commits), rather than the Eigen::Ref instance itself. This moves the policy override into a struct so that code that wants to avoid it (or wants to provide some other Return-type-conditional override) can create a specialization of return_value_policy_override<Return> in order to override the override. This lets an Eigen::Ref-returning function be bound with `rvp::copy`, for example, to specify that the data should be copied into a new numpy array rather than referenced, or `rvp::reference_internal` to indicate that it should be referenced, but a keep-alive used (actually, we used the array's `base` rather than a py::keep_alive in such a case, but it accomplishes the same thing).
2017-01-20 05:59:26 +00:00
// When a value returned from a C++ function is being cast back to Python, we almost always want to
// force `policy = move`, regardless of the return value policy the function/method was declared
stl.h: propagate return value policies to type-specific casters (#1455) * stl.h: propagate return value policies to type-specific casters Return value policies for containers like those handled in in 'stl.h' are currently broken. The problem is that detail::return_value_policy_override<C>::policy() always returns 'move' when given a non-pointer/reference type, e.g. 'std::vector<...>'. This is sensible behavior for custom types that are exposed via 'py::class_<>', but it does not make sense for types that are handled by other type casters (STL containers, Eigen matrices, etc.). This commit changes the behavior so that detail::return_value_policy_override only becomes active when the type caster derives from type_caster_generic. Furthermore, the override logic is called recursively in STL type casters to enable key/value-specific behavior.
2018-07-17 14:56:26 +00:00
// with.
Add an ability to avoid forcing rvp::move Eigen::Ref objects, when returned, are almost always returned as rvalues; what's important is the data they reference, not the outer shell, and so we want to be able to use `::copy`, `::reference_internal`, etc. to refer to the data the Eigen::Ref references (in the following commits), rather than the Eigen::Ref instance itself. This moves the policy override into a struct so that code that wants to avoid it (or wants to provide some other Return-type-conditional override) can create a specialization of return_value_policy_override<Return> in order to override the override. This lets an Eigen::Ref-returning function be bound with `rvp::copy`, for example, to specify that the data should be copied into a new numpy array rather than referenced, or `rvp::reference_internal` to indicate that it should be referenced, but a keep-alive used (actually, we used the array's `base` rather than a py::keep_alive in such a case, but it accomplishes the same thing).
2017-01-20 05:59:26 +00:00
template <typename Return, typename SFINAE = void> struct return_value_policy_override {
stl.h: propagate return value policies to type-specific casters (#1455) * stl.h: propagate return value policies to type-specific casters Return value policies for containers like those handled in in 'stl.h' are currently broken. The problem is that detail::return_value_policy_override<C>::policy() always returns 'move' when given a non-pointer/reference type, e.g. 'std::vector<...>'. This is sensible behavior for custom types that are exposed via 'py::class_<>', but it does not make sense for types that are handled by other type casters (STL containers, Eigen matrices, etc.). This commit changes the behavior so that detail::return_value_policy_override only becomes active when the type caster derives from type_caster_generic. Furthermore, the override logic is called recursively in STL type casters to enable key/value-specific behavior.
2018-07-17 14:56:26 +00:00
static return_value_policy policy(return_value_policy p) { return p; }
};
template <typename Return> struct return_value_policy_override<Return,
detail::enable_if_t<std::is_base_of<type_caster_generic, make_caster<Return>>::value, void>> {
Add an ability to avoid forcing rvp::move Eigen::Ref objects, when returned, are almost always returned as rvalues; what's important is the data they reference, not the outer shell, and so we want to be able to use `::copy`, `::reference_internal`, etc. to refer to the data the Eigen::Ref references (in the following commits), rather than the Eigen::Ref instance itself. This moves the policy override into a struct so that code that wants to avoid it (or wants to provide some other Return-type-conditional override) can create a specialization of return_value_policy_override<Return> in order to override the override. This lets an Eigen::Ref-returning function be bound with `rvp::copy`, for example, to specify that the data should be copied into a new numpy array rather than referenced, or `rvp::reference_internal` to indicate that it should be referenced, but a keep-alive used (actually, we used the array's `base` rather than a py::keep_alive in such a case, but it accomplishes the same thing).
2017-01-20 05:59:26 +00:00
static return_value_policy policy(return_value_policy p) {
fixed regression in STL type caster RVPs (fixes #1561) (#1603)
2018-11-09 19:12:46 +00:00
return !std::is_lvalue_reference<Return>::value &&
!std::is_pointer<Return>::value
? return_value_policy::move : p;
Add an ability to avoid forcing rvp::move Eigen::Ref objects, when returned, are almost always returned as rvalues; what's important is the data they reference, not the outer shell, and so we want to be able to use `::copy`, `::reference_internal`, etc. to refer to the data the Eigen::Ref references (in the following commits), rather than the Eigen::Ref instance itself. This moves the policy override into a struct so that code that wants to avoid it (or wants to provide some other Return-type-conditional override) can create a specialization of return_value_policy_override<Return> in order to override the override. This lets an Eigen::Ref-returning function be bound with `rvp::copy`, for example, to specify that the data should be copied into a new numpy array rather than referenced, or `rvp::reference_internal` to indicate that it should be referenced, but a keep-alive used (actually, we used the array's `base` rather than a py::keep_alive in such a case, but it accomplishes the same thing).
2017-01-20 05:59:26 +00:00
}
};
Store a static type_caster rather than the basic type
2016-09-11 16:17:41 +00:00
// Basic python -> C++ casting; throws if casting fails
Fix build under debug mode Take load_type by nested type_caster template arguments instead of by full type_caster type.
2016-09-12 20:21:40 +00:00
template <typename T, typename SFINAE> type_caster<T, SFINAE> &load_type(type_caster<T, SFINAE> &conv, const handle &handle) {
more informative error message when py::cast fails
2016-07-01 14:07:24 +00:00
if (!conv.load(handle, true)) {
#if defined(NDEBUG)
throw cast_error("Unable to cast Python instance to C++ type (compile in debug mode for details)");
#else
throw cast_error("Unable to cast Python instance of type " +
Remove spurious quote in error message. (#1202)
2017-12-04 02:17:16 +00:00
(std::string) str(handle.get_type()) + " to C++ type '" + type_id<T>() + "'");
more informative error message when py::cast fails
2016-07-01 14:07:24 +00:00
#endif
}
Update OVERLOAD macros to support ref/ptr return type overloads This adds a static local variable (in dead code unless actually needed) in the overload code that is used for storage if the overload is for some convert-by-value type (such as numeric values or std::string). This has limitations (as written up in the advanced doc), but is better than simply not being able to overload reference or pointer methods.
2016-09-08 18:49:43 +00:00
return conv;
}
Store a static type_caster rather than the basic type
2016-09-11 16:17:41 +00:00
// Wrapper around the above that also constructs and returns a type_caster
template <typename T> make_caster<T> load_type(const handle &handle) {
make_caster<T> conv;
load_type(conv, handle);
return conv;
}
Update OVERLOAD macros to support ref/ptr return type overloads This adds a static local variable (in dead code unless actually needed) in the overload code that is used for storage if the overload is for some convert-by-value type (such as numeric values or std::string). This has limitations (as written up in the advanced doc), but is better than simply not being able to overload reference or pointer methods.
2016-09-08 18:49:43 +00:00
NAMESPACE_END(detail)
Add py::reinterpret_borrow<T>()/steal<T>() for low-level unchecked casts The pytype converting constructors are convenient and safe for user code, but for library internals the additional type checks and possible conversions are sometimes not desired. `reinterpret_borrow<T>()` and `reinterpret_steal<T>()` serve as the low-level unsafe counterparts of `cast<T>()`. This deprecates the `object(handle, bool)` constructor. Renamed `borrowed` parameter to `is_borrowed` to avoid shadowing warnings on MSVC.
2016-10-28 01:08:15 +00:00
// pytype -> C++ type
Add default and converting constructors for all concrete Python types * Deprecate the `py::object::str()` member function since `py::str(obj)` is now equivalent and preferred * Make `py::repr()` a free function * Make sure obj.cast<T>() works as expected when T is a Python type `obj.cast<T>()` should be the same as `T(obj)`, i.e. it should convert the given object to a different Python type. However, `obj.cast<T>()` usually calls `type_caster::load()` which only checks the type without doing any actual conversion. That causes a very unexpected `cast_error`. This commit makes it so that `obj.cast<T>()` and `T(obj)` are the same when T is a Python type. * Simplify pytypes converting constructor implementation It's not necessary to maintain a full set of converting constructors and assignment operators + const& and &&. A single converting const& constructor will work and there is no impact on binary size. On the other hand, the conversion functions can be significantly simplified.
2016-10-25 20:12:39 +00:00
template <typename T, detail::enable_if_t<!detail::is_pyobject<T>::value, int> = 0>
T cast(const handle &handle) {
Clean up cast operator invocations (#531) This adds a `detail::cast_op<T>(caster)` function which handles the rather verbose: caster.operator typename CasterType::template cast_op_type<T>() which allows various places to use the shorter and clearer: cast_op<T>(caster) instead of the full verbose cast operator invocation.
2016-11-25 17:35:00 +00:00
using namespace detail;
static_assert(!cast_is_temporary_value_reference<T>::value,
Update OVERLOAD macros to support ref/ptr return type overloads This adds a static local variable (in dead code unless actually needed) in the overload code that is used for storage if the overload is for some convert-by-value type (such as numeric values or std::string). This has limitations (as written up in the advanced doc), but is better than simply not being able to overload reference or pointer methods.
2016-09-08 18:49:43 +00:00
"Unable to cast type to reference: value is local to type caster");
Clean up cast operator invocations (#531) This adds a `detail::cast_op<T>(caster)` function which handles the rather verbose: caster.operator typename CasterType::template cast_op_type<T>() which allows various places to use the shorter and clearer: cast_op<T>(caster) instead of the full verbose cast operator invocation.
2016-11-25 17:35:00 +00:00
return cast_op<T>(load_type<T>(handle));
Initial commit
2015-07-05 18:05:44 +00:00
}
Add py::reinterpret_borrow<T>()/steal<T>() for low-level unchecked casts The pytype converting constructors are convenient and safe for user code, but for library internals the additional type checks and possible conversions are sometimes not desired. `reinterpret_borrow<T>()` and `reinterpret_steal<T>()` serve as the low-level unsafe counterparts of `cast<T>()`. This deprecates the `object(handle, bool)` constructor. Renamed `borrowed` parameter to `is_borrowed` to avoid shadowing warnings on MSVC.
2016-10-28 01:08:15 +00:00
// pytype -> pytype (calls converting constructor)
Add default and converting constructors for all concrete Python types * Deprecate the `py::object::str()` member function since `py::str(obj)` is now equivalent and preferred * Make `py::repr()` a free function * Make sure obj.cast<T>() works as expected when T is a Python type `obj.cast<T>()` should be the same as `T(obj)`, i.e. it should convert the given object to a different Python type. However, `obj.cast<T>()` usually calls `type_caster::load()` which only checks the type without doing any actual conversion. That causes a very unexpected `cast_error`. This commit makes it so that `obj.cast<T>()` and `T(obj)` are the same when T is a Python type. * Simplify pytypes converting constructor implementation It's not necessary to maintain a full set of converting constructors and assignment operators + const& and &&. A single converting const& constructor will work and there is no impact on binary size. On the other hand, the conversion functions can be significantly simplified.
2016-10-25 20:12:39 +00:00
template <typename T, detail::enable_if_t<detail::is_pyobject<T>::value, int> = 0>
Add py::reinterpret_borrow<T>()/steal<T>() for low-level unchecked casts The pytype converting constructors are convenient and safe for user code, but for library internals the additional type checks and possible conversions are sometimes not desired. `reinterpret_borrow<T>()` and `reinterpret_steal<T>()` serve as the low-level unsafe counterparts of `cast<T>()`. This deprecates the `object(handle, bool)` constructor. Renamed `borrowed` parameter to `is_borrowed` to avoid shadowing warnings on MSVC.
2016-10-28 01:08:15 +00:00
T cast(const handle &handle) { return T(reinterpret_borrow<object>(handle)); }
Add default and converting constructors for all concrete Python types * Deprecate the `py::object::str()` member function since `py::str(obj)` is now equivalent and preferred * Make `py::repr()` a free function * Make sure obj.cast<T>() works as expected when T is a Python type `obj.cast<T>()` should be the same as `T(obj)`, i.e. it should convert the given object to a different Python type. However, `obj.cast<T>()` usually calls `type_caster::load()` which only checks the type without doing any actual conversion. That causes a very unexpected `cast_error`. This commit makes it so that `obj.cast<T>()` and `T(obj)` are the same when T is a Python type. * Simplify pytypes converting constructor implementation It's not necessary to maintain a full set of converting constructors and assignment operators + const& and &&. A single converting const& constructor will work and there is no impact on binary size. On the other hand, the conversion functions can be significantly simplified.
2016-10-25 20:12:39 +00:00
Add py::reinterpret_borrow<T>()/steal<T>() for low-level unchecked casts The pytype converting constructors are convenient and safe for user code, but for library internals the additional type checks and possible conversions are sometimes not desired. `reinterpret_borrow<T>()` and `reinterpret_steal<T>()` serve as the low-level unsafe counterparts of `cast<T>()`. This deprecates the `object(handle, bool)` constructor. Renamed `borrowed` parameter to `is_borrowed` to avoid shadowing warnings on MSVC.
2016-10-28 01:08:15 +00:00
// C++ type -> py::object
Add default and converting constructors for all concrete Python types * Deprecate the `py::object::str()` member function since `py::str(obj)` is now equivalent and preferred * Make `py::repr()` a free function * Make sure obj.cast<T>() works as expected when T is a Python type `obj.cast<T>()` should be the same as `T(obj)`, i.e. it should convert the given object to a different Python type. However, `obj.cast<T>()` usually calls `type_caster::load()` which only checks the type without doing any actual conversion. That causes a very unexpected `cast_error`. This commit makes it so that `obj.cast<T>()` and `T(obj)` are the same when T is a Python type. * Simplify pytypes converting constructor implementation It's not necessary to maintain a full set of converting constructors and assignment operators + const& and &&. A single converting const& constructor will work and there is no impact on binary size. On the other hand, the conversion functions can be significantly simplified.
2016-10-25 20:12:39 +00:00
template <typename T, detail::enable_if_t<!detail::is_pyobject<T>::value, int> = 0>
object cast(const T &value, return_value_policy policy = return_value_policy::automatic_reference,
handle parent = handle()) {
Initial commit
2015-07-05 18:05:44 +00:00
if (policy == return_value_policy::automatic)
policy = std::is_pointer<T>::value ? return_value_policy::take_ownership : return_value_policy::copy;
New automatic return value policy for cat() and make_tuple(), fixed an ambiguity issue
2016-04-14 12:26:13 +00:00
else if (policy == return_value_policy::automatic_reference)
policy = std::is_pointer<T>::value ? return_value_policy::reference : return_value_policy::copy;
Add py::reinterpret_borrow<T>()/steal<T>() for low-level unchecked casts The pytype converting constructors are convenient and safe for user code, but for library internals the additional type checks and possible conversions are sometimes not desired. `reinterpret_borrow<T>()` and `reinterpret_steal<T>()` serve as the low-level unsafe counterparts of `cast<T>()`. This deprecates the `object(handle, bool)` constructor. Renamed `borrowed` parameter to `is_borrowed` to avoid shadowing warnings on MSVC.
2016-10-28 01:08:15 +00:00
return reinterpret_steal<object>(detail::make_caster<T>::cast(value, policy, parent));
Initial commit
2015-07-05 18:05:44 +00:00
}
minor cleanups
2016-05-03 11:28:40 +00:00
template <typename T> T handle::cast() const { return pybind11::cast<T>(*this); }
Add const modifier to handle::cast.
2015-12-26 18:01:28 +00:00
template <> inline void handle::cast() const { return; }
Initial commit
2015-07-05 18:05:44 +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
template <typename T>
Change all_of_t/any_of_t to all_of/any_of, add none_of This replaces the current `all_of_t<Pred, Ts...>` with `all_of<Ts...>`, with previous use of `all_of_t<Pred, Ts...>` becoming `all_of<Pred<Ts>...>` (and similarly for `any_of_t`). It also adds a `none_of<Ts...>`, a shortcut for `negation<any_of<Ts...>>`. This allows `all_of` and `any_of` to be used a bit more flexible, e.g. in cases where several predicates need to be tested for the same type instead of the same predicate for multiple types. This commit replaces the implementation with a more efficient version for non-MSVC. For MSVC, this changes the workaround to use the built-in, recursive std::conjunction/std::disjunction instead. This also removes the `count_t` since `any_of_t` and `all_of_t` were the only things using it. This commit also rearranges some of the future std imports to use actual `std` implementations for C++14/17 features when under the appropriate compiler mode, as we were already doing for a few things (like index_sequence). Most of these aren't saving much (the implementation for enable_if_t, for example, is trivial), but I think it makes the intention of the code instantly clear. It also enables MSVC's native std::index_sequence support.
2016-12-12 23:11:49 +00:00
detail::enable_if_t<!detail::move_never<T>::value, T> move(object &&obj) {
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
if (obj.ref_count() > 1)
#if defined(NDEBUG)
throw cast_error("Unable to cast Python instance to C++ rvalue: instance has multiple references"
" (compile in debug mode for details)");
#else
Add default and converting constructors for all concrete Python types * Deprecate the `py::object::str()` member function since `py::str(obj)` is now equivalent and preferred * Make `py::repr()` a free function * Make sure obj.cast<T>() works as expected when T is a Python type `obj.cast<T>()` should be the same as `T(obj)`, i.e. it should convert the given object to a different Python type. However, `obj.cast<T>()` usually calls `type_caster::load()` which only checks the type without doing any actual conversion. That causes a very unexpected `cast_error`. This commit makes it so that `obj.cast<T>()` and `T(obj)` are the same when T is a Python type. * Simplify pytypes converting constructor implementation It's not necessary to maintain a full set of converting constructors and assignment operators + const& and &&. A single converting const& constructor will work and there is no impact on binary size. On the other hand, the conversion functions can be significantly simplified.
2016-10-25 20:12:39 +00:00
throw cast_error("Unable to move from Python " + (std::string) str(obj.get_type()) +
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
" instance to C++ " + type_id<T>() + " instance: instance has multiple references");
#endif
// Move into a temporary and return that, because the reference may be a local value of `conv`
Update OVERLOAD macros to support ref/ptr return type overloads This adds a static local variable (in dead code unless actually needed) in the overload code that is used for storage if the overload is for some convert-by-value type (such as numeric values or std::string). This has limitations (as written up in the advanced doc), but is better than simply not being able to overload reference or pointer methods.
2016-09-08 18:49:43 +00:00
T ret = std::move(detail::load_type<T>(obj).operator T&());
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
return ret;
}
// Calling cast() on an rvalue calls pybind::cast with the object rvalue, which does:
// - If we have to move (because T has no copy constructor), do it. This will fail if the moved
// object has multiple references, but trying to copy will fail to compile.
// - If both movable and copyable, check ref count: if 1, move; otherwise copy
// - Otherwise (not movable), copy.
Update OVERLOAD macros to support ref/ptr return type overloads This adds a static local variable (in dead code unless actually needed) in the overload code that is used for storage if the overload is for some convert-by-value type (such as numeric values or std::string). This has limitations (as written up in the advanced doc), but is better than simply not being able to overload reference or pointer methods.
2016-09-08 18:49:43 +00:00
template <typename T> detail::enable_if_t<detail::move_always<T>::value, T> cast(object &&object) {
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
return move<T>(std::move(object));
}
Update OVERLOAD macros to support ref/ptr return type overloads This adds a static local variable (in dead code unless actually needed) in the overload code that is used for storage if the overload is for some convert-by-value type (such as numeric values or std::string). This has limitations (as written up in the advanced doc), but is better than simply not being able to overload reference or pointer methods.
2016-09-08 18:49:43 +00:00
template <typename T> detail::enable_if_t<detail::move_if_unreferenced<T>::value, T> cast(object &&object) {
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
if (object.ref_count() > 1)
return cast<T>(object);
else
return move<T>(std::move(object));
}
Update OVERLOAD macros to support ref/ptr return type overloads This adds a static local variable (in dead code unless actually needed) in the overload code that is used for storage if the overload is for some convert-by-value type (such as numeric values or std::string). This has limitations (as written up in the advanced doc), but is better than simply not being able to overload reference or pointer methods.
2016-09-08 18:49:43 +00:00
template <typename T> detail::enable_if_t<detail::move_never<T>::value, T> cast(object &&object) {
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
return cast<T>(object);
}
template <typename T> T object::cast() const & { return pybind11::cast<T>(*this); }
template <typename T> T object::cast() && { return pybind11::cast<T>(std::move(*this)); }
template <> inline void object::cast() const & { return; }
template <> inline void object::cast() && { return; }
Update OVERLOAD macros to support ref/ptr return type overloads This adds a static local variable (in dead code unless actually needed) in the overload code that is used for storage if the overload is for some convert-by-value type (such as numeric values or std::string). This has limitations (as written up in the advanced doc), but is better than simply not being able to overload reference or pointer methods.
2016-09-08 18:49:43 +00:00
NAMESPACE_BEGIN(detail)
Adds automatic casting on assignment of non-pyobject types (#551) This adds automatic casting when assigning to python types like dict, list, and attributes. Instead of: dict["key"] = py::cast(val); m.attr("foo") = py::cast(true); list.append(py::cast(42)); you can now simply write: dict["key"] = val; m.attr("foo") = true; list.append(42); Casts needing extra parameters (e.g. for a non-default rvp) still require the py::cast() call. set::add() is also supported. All usage is channeled through a SFINAE implementation which either just returns or casts. Combined non-converting handle and autocasting template methods via a helper method that either just returns (handle) or casts (C++ type).
2016-12-12 22:42:52 +00:00
// Declared in pytypes.h:
template <typename T, enable_if_t<!is_pyobject<T>::value, int>>
object object_or_cast(T &&o) { return pybind11::cast(std::forward<T>(o)); }
Store a static type_caster rather than the basic type
2016-09-11 16:17:41 +00:00
struct overload_unused {}; // Placeholder type for the unneeded (and dead code) static variable in the OVERLOAD_INT macro
template <typename ret_type> using overload_caster_t = conditional_t<
cast_is_temporary_value_reference<ret_type>::value, make_caster<ret_type>, overload_unused>;
Update OVERLOAD macros to support ref/ptr return type overloads This adds a static local variable (in dead code unless actually needed) in the overload code that is used for storage if the overload is for some convert-by-value type (such as numeric values or std::string). This has limitations (as written up in the advanced doc), but is better than simply not being able to overload reference or pointer methods.
2016-09-08 18:49:43 +00:00
// Trampoline use: for reference/pointer types to value-converted values, we do a value cast, then
// store the result in the given variable. For other types, this is a no-op.
Store a static type_caster rather than the basic type
2016-09-11 16:17:41 +00:00
template <typename T> enable_if_t<cast_is_temporary_value_reference<T>::value, T> cast_ref(object &&o, make_caster<T> &caster) {
Clean up cast operator invocations (#531) This adds a `detail::cast_op<T>(caster)` function which handles the rather verbose: caster.operator typename CasterType::template cast_op_type<T>() which allows various places to use the shorter and clearer: cast_op<T>(caster) instead of the full verbose cast operator invocation.
2016-11-25 17:35:00 +00:00
return cast_op<T>(load_type(caster, o));
Update OVERLOAD macros to support ref/ptr return type overloads This adds a static local variable (in dead code unless actually needed) in the overload code that is used for storage if the overload is for some convert-by-value type (such as numeric values or std::string). This has limitations (as written up in the advanced doc), but is better than simply not being able to overload reference or pointer methods.
2016-09-08 18:49:43 +00:00
}
Store a static type_caster rather than the basic type
2016-09-11 16:17:41 +00:00
template <typename T> enable_if_t<!cast_is_temporary_value_reference<T>::value, T> cast_ref(object &&, overload_unused &) {
Update OVERLOAD macros to support ref/ptr return type overloads This adds a static local variable (in dead code unless actually needed) in the overload code that is used for storage if the overload is for some convert-by-value type (such as numeric values or std::string). This has limitations (as written up in the advanced doc), but is better than simply not being able to overload reference or pointer methods.
2016-09-08 18:49:43 +00:00
pybind11_fail("Internal error: cast_ref fallback invoked"); }
// Trampoline use: Having a pybind11::cast with an invalid reference type is going to static_assert, even
// though if it's in dead code, so we provide a "trampoline" to pybind11::cast that only does anything in
// cases where pybind11::cast is valid.
template <typename T> enable_if_t<!cast_is_temporary_value_reference<T>::value, T> cast_safe(object &&o) {
return pybind11::cast<T>(std::move(o)); }
template <typename T> enable_if_t<cast_is_temporary_value_reference<T>::value, T> cast_safe(object &&) {
pybind11_fail("Internal error: cast_safe fallback invoked"); }
template <> inline void cast_safe<void>(object &&) {}
NAMESPACE_END(detail)
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
Fix pybind11 interoperability with Clang trunk (#1269)
2018-02-06 14:40:50 +00:00
template <return_value_policy policy = return_value_policy::automatic_reference>
tuple make_tuple() { return tuple(0); }
New automatic return value policy for cat() and make_tuple(), fixed an ambiguity issue
2016-04-14 12:26:13 +00:00
template <return_value_policy policy = return_value_policy::automatic_reference,
minor cleanups
2016-05-03 11:28:40 +00:00
typename... Args> tuple make_tuple(Args&&... args_) {
Improve make_tuple error message under debugging When make_tuple fails (for example, when print() is called with a non-convertible argument, as in #778) the error message a less helpful than it could be: make_tuple(): unable to convert arguments of types 'std::tuple<type1, type2>' to Python object There is no actual std::tuple involved (only a parameter pack and a Python tuple), but it also doesn't immediately reveal which type caused the problem. This commit changes the debugging mode output to show just the problematic type: make_tuple(): unable to convert argument of type 'type2' to Python object
2017-04-05 14:51:02 +00:00
constexpr size_t size = sizeof...(Args);
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
std::array<object, size> args {
Add py::reinterpret_borrow<T>()/steal<T>() for low-level unchecked casts The pytype converting constructors are convenient and safe for user code, but for library internals the additional type checks and possible conversions are sometimes not desired. `reinterpret_borrow<T>()` and `reinterpret_steal<T>()` serve as the low-level unsafe counterparts of `cast<T>()`. This deprecates the `object(handle, bool)` constructor. Renamed `borrowed` parameter to `is_borrowed` to avoid shadowing warnings on MSVC.
2016-10-28 01:08:15 +00:00
{ reinterpret_steal<object>(detail::make_caster<Args>::cast(
std::forward<Args>(args_), policy, nullptr))... }
Initial commit
2015-07-05 18:05:44 +00:00
};
Improve make_tuple error message under debugging When make_tuple fails (for example, when print() is called with a non-convertible argument, as in #778) the error message a less helpful than it could be: make_tuple(): unable to convert arguments of types 'std::tuple<type1, type2>' to Python object There is no actual std::tuple involved (only a parameter pack and a Python tuple), but it also doesn't immediately reveal which type caused the problem. This commit changes the debugging mode output to show just the problematic type: make_tuple(): unable to convert argument of type 'type2' to Python object
2017-04-05 14:51:02 +00:00
for (size_t i = 0; i < args.size(); i++) {
if (!args[i]) {
more informative error message when py::make_tuple fails
2016-07-01 18:35:35 +00:00
#if defined(NDEBUG)
throw cast_error("make_tuple(): unable to convert arguments to Python object (compile in debug mode for details)");
#else
Fix -Wmissing-braces warning
2017-04-05 22:00:38 +00:00
std::array<std::string, size> argtypes { {type_id<Args>()...} };
Improve make_tuple error message under debugging When make_tuple fails (for example, when print() is called with a non-convertible argument, as in #778) the error message a less helpful than it could be: make_tuple(): unable to convert arguments of types 'std::tuple<type1, type2>' to Python object There is no actual std::tuple involved (only a parameter pack and a Python tuple), but it also doesn't immediately reveal which type caused the problem. This commit changes the debugging mode output to show just the problematic type: make_tuple(): unable to convert argument of type 'type2' to Python object
2017-04-05 14:51:02 +00:00
throw cast_error("make_tuple(): unable to convert argument of type '" +
argtypes[i] + "' to Python object");
more informative error message when py::make_tuple fails
2016-07-01 18:35:35 +00:00
#endif
}
}
added variadic make_tuple() function
2016-04-12 22:56:17 +00:00
tuple result(size);
Initial commit
2015-07-05 18:05:44 +00:00
int counter = 0;
general cleanup of the codebase - new pybind11::base<> attribute to indicate a subclass relationship - unified infrastructure for parsing variadic arguments in class_ and cpp_function - use 'handle' and 'object' more consistently everywhere
2016-01-17 21:36:44 +00:00
for (auto &arg_value : args)
added variadic make_tuple() function
2016-04-12 22:56:17 +00:00
PyTuple_SET_ITEM(result.ptr(), counter++, arg_value.release().ptr());
return result;
}
Automate generation of reference docs with doxygen and breathe (#598) * Make 'any' the default markup role for Sphinx docs * Automate generation of reference docs with doxygen and breathe * Improve reference docs coverage
2017-01-31 15:54:08 +00:00
/// \ingroup annotations
Add support for non-converting arguments This adds support for controlling the `convert` flag of arguments through the py::arg annotation. This then allows arguments to be flagged as non-converting, which the type_caster is able to use to request different behaviour. Currently, AFAICS `convert` is only used for type converters of regular pybind11-registered types; all of the other core type_casters ignore it. We can, however, repurpose it to control internal conversion of converters like Eigen and `array`: most usefully to give callers a way to disable the conversion that would otherwise occur when a `Eigen::Ref<const Eigen::Matrix>` argument is passed a numpy array that requires conversion (either because it has an incompatible stride or the wrong dtype). Specifying a noconvert looks like one of these: m.def("f1", &f, "a"_a.noconvert() = "default"); // Named, default, noconvert m.def("f2", &f, "a"_a.noconvert()); // Named, no default, no converting m.def("f3", &f, py::arg().noconvert()); // Unnamed, no default, no converting (The last part--being able to declare a py::arg without a name--is new: previous py::arg() only accepted named keyword arguments). Such an non-convert argument is then passed `convert = false` by the type caster when loading the argument. Whether this has an effect is up to the type caster itself, but as mentioned above, this would be extremely helpful for the Eigen support to give a nicer way to specify a "no-copy" mode than the custom wrapper in the current PR, and moreover isn't an Eigen-specific hack.
2017-01-23 08:50:00 +00:00
/// Annotation for arguments
Make keyword argument hold a py::object instead of T* With this change arg_t is no longer a template, but it must remain so for backward compatibility. Thus, a non-template arg_v is introduced, while a dummy template alias arg_t is there to keep old code from breaking. This can be remove in the next major release. The implementation of arg_v also needed to be placed a little earlier in the headers because it's not a template any more and unpacking_collector needs more than a forward declaration.
2016-09-05 22:49:21 +00:00
struct arg {
Add support for non-converting arguments This adds support for controlling the `convert` flag of arguments through the py::arg annotation. This then allows arguments to be flagged as non-converting, which the type_caster is able to use to request different behaviour. Currently, AFAICS `convert` is only used for type converters of regular pybind11-registered types; all of the other core type_casters ignore it. We can, however, repurpose it to control internal conversion of converters like Eigen and `array`: most usefully to give callers a way to disable the conversion that would otherwise occur when a `Eigen::Ref<const Eigen::Matrix>` argument is passed a numpy array that requires conversion (either because it has an incompatible stride or the wrong dtype). Specifying a noconvert looks like one of these: m.def("f1", &f, "a"_a.noconvert() = "default"); // Named, default, noconvert m.def("f2", &f, "a"_a.noconvert()); // Named, no default, no converting m.def("f3", &f, py::arg().noconvert()); // Unnamed, no default, no converting (The last part--being able to declare a py::arg without a name--is new: previous py::arg() only accepted named keyword arguments). Such an non-convert argument is then passed `convert = false` by the type caster when loading the argument. Whether this has an effect is up to the type caster itself, but as mentioned above, this would be extremely helpful for the Eigen support to give a nicer way to specify a "no-copy" mode than the custom wrapper in the current PR, and moreover isn't an Eigen-specific hack.
2017-01-23 08:50:00 +00:00
/// Constructs an argument with the name of the argument; if null or omitted, this is a positional argument.
Allow py::arg().none(false) argument attribute This attribute lets you disable (or explicitly enable) passing None to an argument that otherwise would allow it by accepting a value by raw pointer or shared_ptr.
2017-05-17 15:55:43 +00:00
constexpr explicit arg(const char *name = nullptr) : name(name), flag_noconvert(false), flag_none(true) { }
Automate generation of reference docs with doxygen and breathe (#598) * Make 'any' the default markup role for Sphinx docs * Automate generation of reference docs with doxygen and breathe * Improve reference docs coverage
2017-01-31 15:54:08 +00:00
/// Assign a value to this argument
Make keyword argument hold a py::object instead of T* With this change arg_t is no longer a template, but it must remain so for backward compatibility. Thus, a non-template arg_v is introduced, while a dummy template alias arg_t is there to keep old code from breaking. This can be remove in the next major release. The implementation of arg_v also needed to be placed a little earlier in the headers because it's not a template any more and unpacking_collector needs more than a forward declaration.
2016-09-05 22:49:21 +00:00
template <typename T> arg_v operator=(T &&value) const;
Add support for non-converting arguments This adds support for controlling the `convert` flag of arguments through the py::arg annotation. This then allows arguments to be flagged as non-converting, which the type_caster is able to use to request different behaviour. Currently, AFAICS `convert` is only used for type converters of regular pybind11-registered types; all of the other core type_casters ignore it. We can, however, repurpose it to control internal conversion of converters like Eigen and `array`: most usefully to give callers a way to disable the conversion that would otherwise occur when a `Eigen::Ref<const Eigen::Matrix>` argument is passed a numpy array that requires conversion (either because it has an incompatible stride or the wrong dtype). Specifying a noconvert looks like one of these: m.def("f1", &f, "a"_a.noconvert() = "default"); // Named, default, noconvert m.def("f2", &f, "a"_a.noconvert()); // Named, no default, no converting m.def("f3", &f, py::arg().noconvert()); // Unnamed, no default, no converting (The last part--being able to declare a py::arg without a name--is new: previous py::arg() only accepted named keyword arguments). Such an non-convert argument is then passed `convert = false` by the type caster when loading the argument. Whether this has an effect is up to the type caster itself, but as mentioned above, this would be extremely helpful for the Eigen support to give a nicer way to specify a "no-copy" mode than the custom wrapper in the current PR, and moreover isn't an Eigen-specific hack.
2017-01-23 08:50:00 +00:00
/// Indicate that the type should not be converted in the type caster
arg &noconvert(bool flag = true) { flag_noconvert = flag; return *this; }
Allow py::arg().none(false) argument attribute This attribute lets you disable (or explicitly enable) passing None to an argument that otherwise would allow it by accepting a value by raw pointer or shared_ptr.
2017-05-17 15:55:43 +00:00
/// Indicates that the argument should/shouldn't allow None (e.g. for nullable pointer args)
arg &none(bool flag = true) { flag_none = flag; return *this; }
Make keyword argument hold a py::object instead of T* With this change arg_t is no longer a template, but it must remain so for backward compatibility. Thus, a non-template arg_v is introduced, while a dummy template alias arg_t is there to keep old code from breaking. This can be remove in the next major release. The implementation of arg_v also needed to be placed a little earlier in the headers because it's not a template any more and unpacking_collector needs more than a forward declaration.
2016-09-05 22:49:21 +00:00
Add support for non-converting arguments This adds support for controlling the `convert` flag of arguments through the py::arg annotation. This then allows arguments to be flagged as non-converting, which the type_caster is able to use to request different behaviour. Currently, AFAICS `convert` is only used for type converters of regular pybind11-registered types; all of the other core type_casters ignore it. We can, however, repurpose it to control internal conversion of converters like Eigen and `array`: most usefully to give callers a way to disable the conversion that would otherwise occur when a `Eigen::Ref<const Eigen::Matrix>` argument is passed a numpy array that requires conversion (either because it has an incompatible stride or the wrong dtype). Specifying a noconvert looks like one of these: m.def("f1", &f, "a"_a.noconvert() = "default"); // Named, default, noconvert m.def("f2", &f, "a"_a.noconvert()); // Named, no default, no converting m.def("f3", &f, py::arg().noconvert()); // Unnamed, no default, no converting (The last part--being able to declare a py::arg without a name--is new: previous py::arg() only accepted named keyword arguments). Such an non-convert argument is then passed `convert = false` by the type caster when loading the argument. Whether this has an effect is up to the type caster itself, but as mentioned above, this would be extremely helpful for the Eigen support to give a nicer way to specify a "no-copy" mode than the custom wrapper in the current PR, and moreover isn't an Eigen-specific hack.
2017-01-23 08:50:00 +00:00
const char *name; ///< If non-null, this is a named kwargs argument
bool flag_noconvert : 1; ///< If set, do not allow conversion (requires a supporting type caster!)
Allow py::arg().none(false) argument attribute This attribute lets you disable (or explicitly enable) passing None to an argument that otherwise would allow it by accepting a value by raw pointer or shared_ptr.
2017-05-17 15:55:43 +00:00
bool flag_none : 1; ///< If set (the default), allow None to be passed to this argument
Make keyword argument hold a py::object instead of T* With this change arg_t is no longer a template, but it must remain so for backward compatibility. Thus, a non-template arg_v is introduced, while a dummy template alias arg_t is there to keep old code from breaking. This can be remove in the next major release. The implementation of arg_v also needed to be placed a little earlier in the headers because it's not a template any more and unpacking_collector needs more than a forward declaration.
2016-09-05 22:49:21 +00:00
};
Automate generation of reference docs with doxygen and breathe (#598) * Make 'any' the default markup role for Sphinx docs * Automate generation of reference docs with doxygen and breathe * Improve reference docs coverage
2017-01-31 15:54:08 +00:00
/// \ingroup annotations
Add support for non-converting arguments This adds support for controlling the `convert` flag of arguments through the py::arg annotation. This then allows arguments to be flagged as non-converting, which the type_caster is able to use to request different behaviour. Currently, AFAICS `convert` is only used for type converters of regular pybind11-registered types; all of the other core type_casters ignore it. We can, however, repurpose it to control internal conversion of converters like Eigen and `array`: most usefully to give callers a way to disable the conversion that would otherwise occur when a `Eigen::Ref<const Eigen::Matrix>` argument is passed a numpy array that requires conversion (either because it has an incompatible stride or the wrong dtype). Specifying a noconvert looks like one of these: m.def("f1", &f, "a"_a.noconvert() = "default"); // Named, default, noconvert m.def("f2", &f, "a"_a.noconvert()); // Named, no default, no converting m.def("f3", &f, py::arg().noconvert()); // Unnamed, no default, no converting (The last part--being able to declare a py::arg without a name--is new: previous py::arg() only accepted named keyword arguments). Such an non-convert argument is then passed `convert = false` by the type caster when loading the argument. Whether this has an effect is up to the type caster itself, but as mentioned above, this would be extremely helpful for the Eigen support to give a nicer way to specify a "no-copy" mode than the custom wrapper in the current PR, and moreover isn't an Eigen-specific hack.
2017-01-23 08:50:00 +00:00
/// Annotation for arguments with values
Make keyword argument hold a py::object instead of T* With this change arg_t is no longer a template, but it must remain so for backward compatibility. Thus, a non-template arg_v is introduced, while a dummy template alias arg_t is there to keep old code from breaking. This can be remove in the next major release. The implementation of arg_v also needed to be placed a little earlier in the headers because it's not a template any more and unpacking_collector needs more than a forward declaration.
2016-09-05 22:49:21 +00:00
struct arg_v : arg {
Add support for non-converting arguments This adds support for controlling the `convert` flag of arguments through the py::arg annotation. This then allows arguments to be flagged as non-converting, which the type_caster is able to use to request different behaviour. Currently, AFAICS `convert` is only used for type converters of regular pybind11-registered types; all of the other core type_casters ignore it. We can, however, repurpose it to control internal conversion of converters like Eigen and `array`: most usefully to give callers a way to disable the conversion that would otherwise occur when a `Eigen::Ref<const Eigen::Matrix>` argument is passed a numpy array that requires conversion (either because it has an incompatible stride or the wrong dtype). Specifying a noconvert looks like one of these: m.def("f1", &f, "a"_a.noconvert() = "default"); // Named, default, noconvert m.def("f2", &f, "a"_a.noconvert()); // Named, no default, no converting m.def("f3", &f, py::arg().noconvert()); // Unnamed, no default, no converting (The last part--being able to declare a py::arg without a name--is new: previous py::arg() only accepted named keyword arguments). Such an non-convert argument is then passed `convert = false` by the type caster when loading the argument. Whether this has an effect is up to the type caster itself, but as mentioned above, this would be extremely helpful for the Eigen support to give a nicer way to specify a "no-copy" mode than the custom wrapper in the current PR, and moreover isn't an Eigen-specific hack.
2017-01-23 08:50:00 +00:00
private:
Make keyword argument hold a py::object instead of T* With this change arg_t is no longer a template, but it must remain so for backward compatibility. Thus, a non-template arg_v is introduced, while a dummy template alias arg_t is there to keep old code from breaking. This can be remove in the next major release. The implementation of arg_v also needed to be placed a little earlier in the headers because it's not a template any more and unpacking_collector needs more than a forward declaration.
2016-09-05 22:49:21 +00:00
template <typename T>
Add support for non-converting arguments This adds support for controlling the `convert` flag of arguments through the py::arg annotation. This then allows arguments to be flagged as non-converting, which the type_caster is able to use to request different behaviour. Currently, AFAICS `convert` is only used for type converters of regular pybind11-registered types; all of the other core type_casters ignore it. We can, however, repurpose it to control internal conversion of converters like Eigen and `array`: most usefully to give callers a way to disable the conversion that would otherwise occur when a `Eigen::Ref<const Eigen::Matrix>` argument is passed a numpy array that requires conversion (either because it has an incompatible stride or the wrong dtype). Specifying a noconvert looks like one of these: m.def("f1", &f, "a"_a.noconvert() = "default"); // Named, default, noconvert m.def("f2", &f, "a"_a.noconvert()); // Named, no default, no converting m.def("f3", &f, py::arg().noconvert()); // Unnamed, no default, no converting (The last part--being able to declare a py::arg without a name--is new: previous py::arg() only accepted named keyword arguments). Such an non-convert argument is then passed `convert = false` by the type caster when loading the argument. Whether this has an effect is up to the type caster itself, but as mentioned above, this would be extremely helpful for the Eigen support to give a nicer way to specify a "no-copy" mode than the custom wrapper in the current PR, and moreover isn't an Eigen-specific hack.
2017-01-23 08:50:00 +00:00
arg_v(arg &&base, T &&x, const char *descr = nullptr)
: arg(base),
Add py::reinterpret_borrow<T>()/steal<T>() for low-level unchecked casts The pytype converting constructors are convenient and safe for user code, but for library internals the additional type checks and possible conversions are sometimes not desired. `reinterpret_borrow<T>()` and `reinterpret_steal<T>()` serve as the low-level unsafe counterparts of `cast<T>()`. This deprecates the `object(handle, bool)` constructor. Renamed `borrowed` parameter to `is_borrowed` to avoid shadowing warnings on MSVC.
2016-10-28 01:08:15 +00:00
value(reinterpret_steal<object>(
detail::make_caster<T>::cast(x, return_value_policy::automatic, {})
)),
Make keyword argument hold a py::object instead of T* With this change arg_t is no longer a template, but it must remain so for backward compatibility. Thus, a non-template arg_v is introduced, while a dummy template alias arg_t is there to keep old code from breaking. This can be remove in the next major release. The implementation of arg_v also needed to be placed a little earlier in the headers because it's not a template any more and unpacking_collector needs more than a forward declaration.
2016-09-05 22:49:21 +00:00
descr(descr)
#if !defined(NDEBUG)
, type(type_id<T>())
#endif
{ }
Add support for non-converting arguments This adds support for controlling the `convert` flag of arguments through the py::arg annotation. This then allows arguments to be flagged as non-converting, which the type_caster is able to use to request different behaviour. Currently, AFAICS `convert` is only used for type converters of regular pybind11-registered types; all of the other core type_casters ignore it. We can, however, repurpose it to control internal conversion of converters like Eigen and `array`: most usefully to give callers a way to disable the conversion that would otherwise occur when a `Eigen::Ref<const Eigen::Matrix>` argument is passed a numpy array that requires conversion (either because it has an incompatible stride or the wrong dtype). Specifying a noconvert looks like one of these: m.def("f1", &f, "a"_a.noconvert() = "default"); // Named, default, noconvert m.def("f2", &f, "a"_a.noconvert()); // Named, no default, no converting m.def("f3", &f, py::arg().noconvert()); // Unnamed, no default, no converting (The last part--being able to declare a py::arg without a name--is new: previous py::arg() only accepted named keyword arguments). Such an non-convert argument is then passed `convert = false` by the type caster when loading the argument. Whether this has an effect is up to the type caster itself, but as mentioned above, this would be extremely helpful for the Eigen support to give a nicer way to specify a "no-copy" mode than the custom wrapper in the current PR, and moreover isn't an Eigen-specific hack.
2017-01-23 08:50:00 +00:00
public:
/// Direct construction with name, default, and description
template <typename T>
arg_v(const char *name, T &&x, const char *descr = nullptr)
: arg_v(arg(name), std::forward<T>(x), descr) { }
/// Called internally when invoking `py::arg("a") = value`
template <typename T>
arg_v(const arg &base, T &&x, const char *descr = nullptr)
: arg_v(arg(base), std::forward<T>(x), descr) { }
/// Same as `arg::noconvert()`, but returns *this as arg_v&, not arg&
arg_v &noconvert(bool flag = true) { arg::noconvert(flag); return *this; }
Allow py::arg().none(false) argument attribute This attribute lets you disable (or explicitly enable) passing None to an argument that otherwise would allow it by accepting a value by raw pointer or shared_ptr.
2017-05-17 15:55:43 +00:00
/// Same as `arg::nonone()`, but returns *this as arg_v&, not arg&
arg_v &none(bool flag = true) { arg::none(flag); return *this; }
Add support for non-converting arguments This adds support for controlling the `convert` flag of arguments through the py::arg annotation. This then allows arguments to be flagged as non-converting, which the type_caster is able to use to request different behaviour. Currently, AFAICS `convert` is only used for type converters of regular pybind11-registered types; all of the other core type_casters ignore it. We can, however, repurpose it to control internal conversion of converters like Eigen and `array`: most usefully to give callers a way to disable the conversion that would otherwise occur when a `Eigen::Ref<const Eigen::Matrix>` argument is passed a numpy array that requires conversion (either because it has an incompatible stride or the wrong dtype). Specifying a noconvert looks like one of these: m.def("f1", &f, "a"_a.noconvert() = "default"); // Named, default, noconvert m.def("f2", &f, "a"_a.noconvert()); // Named, no default, no converting m.def("f3", &f, py::arg().noconvert()); // Unnamed, no default, no converting (The last part--being able to declare a py::arg without a name--is new: previous py::arg() only accepted named keyword arguments). Such an non-convert argument is then passed `convert = false` by the type caster when loading the argument. Whether this has an effect is up to the type caster itself, but as mentioned above, this would be extremely helpful for the Eigen support to give a nicer way to specify a "no-copy" mode than the custom wrapper in the current PR, and moreover isn't an Eigen-specific hack.
2017-01-23 08:50:00 +00:00
/// The default value
Make keyword argument hold a py::object instead of T* With this change arg_t is no longer a template, but it must remain so for backward compatibility. Thus, a non-template arg_v is introduced, while a dummy template alias arg_t is there to keep old code from breaking. This can be remove in the next major release. The implementation of arg_v also needed to be placed a little earlier in the headers because it's not a template any more and unpacking_collector needs more than a forward declaration.
2016-09-05 22:49:21 +00:00
object value;
Add support for non-converting arguments This adds support for controlling the `convert` flag of arguments through the py::arg annotation. This then allows arguments to be flagged as non-converting, which the type_caster is able to use to request different behaviour. Currently, AFAICS `convert` is only used for type converters of regular pybind11-registered types; all of the other core type_casters ignore it. We can, however, repurpose it to control internal conversion of converters like Eigen and `array`: most usefully to give callers a way to disable the conversion that would otherwise occur when a `Eigen::Ref<const Eigen::Matrix>` argument is passed a numpy array that requires conversion (either because it has an incompatible stride or the wrong dtype). Specifying a noconvert looks like one of these: m.def("f1", &f, "a"_a.noconvert() = "default"); // Named, default, noconvert m.def("f2", &f, "a"_a.noconvert()); // Named, no default, no converting m.def("f3", &f, py::arg().noconvert()); // Unnamed, no default, no converting (The last part--being able to declare a py::arg without a name--is new: previous py::arg() only accepted named keyword arguments). Such an non-convert argument is then passed `convert = false` by the type caster when loading the argument. Whether this has an effect is up to the type caster itself, but as mentioned above, this would be extremely helpful for the Eigen support to give a nicer way to specify a "no-copy" mode than the custom wrapper in the current PR, and moreover isn't an Eigen-specific hack.
2017-01-23 08:50:00 +00:00
/// The (optional) description of the default value
Make keyword argument hold a py::object instead of T* With this change arg_t is no longer a template, but it must remain so for backward compatibility. Thus, a non-template arg_v is introduced, while a dummy template alias arg_t is there to keep old code from breaking. This can be remove in the next major release. The implementation of arg_v also needed to be placed a little earlier in the headers because it's not a template any more and unpacking_collector needs more than a forward declaration.
2016-09-05 22:49:21 +00:00
const char *descr;
#if !defined(NDEBUG)
Add support for non-converting arguments This adds support for controlling the `convert` flag of arguments through the py::arg annotation. This then allows arguments to be flagged as non-converting, which the type_caster is able to use to request different behaviour. Currently, AFAICS `convert` is only used for type converters of regular pybind11-registered types; all of the other core type_casters ignore it. We can, however, repurpose it to control internal conversion of converters like Eigen and `array`: most usefully to give callers a way to disable the conversion that would otherwise occur when a `Eigen::Ref<const Eigen::Matrix>` argument is passed a numpy array that requires conversion (either because it has an incompatible stride or the wrong dtype). Specifying a noconvert looks like one of these: m.def("f1", &f, "a"_a.noconvert() = "default"); // Named, default, noconvert m.def("f2", &f, "a"_a.noconvert()); // Named, no default, no converting m.def("f3", &f, py::arg().noconvert()); // Unnamed, no default, no converting (The last part--being able to declare a py::arg without a name--is new: previous py::arg() only accepted named keyword arguments). Such an non-convert argument is then passed `convert = false` by the type caster when loading the argument. Whether this has an effect is up to the type caster itself, but as mentioned above, this would be extremely helpful for the Eigen support to give a nicer way to specify a "no-copy" mode than the custom wrapper in the current PR, and moreover isn't an Eigen-specific hack.
2017-01-23 08:50:00 +00:00
/// The C++ type name of the default value (only available when compiled in debug mode)
Make keyword argument hold a py::object instead of T* With this change arg_t is no longer a template, but it must remain so for backward compatibility. Thus, a non-template arg_v is introduced, while a dummy template alias arg_t is there to keep old code from breaking. This can be remove in the next major release. The implementation of arg_v also needed to be placed a little earlier in the headers because it's not a template any more and unpacking_collector needs more than a forward declaration.
2016-09-05 22:49:21 +00:00
std::string type;
#endif
};
template <typename T>
Add support for non-converting arguments This adds support for controlling the `convert` flag of arguments through the py::arg annotation. This then allows arguments to be flagged as non-converting, which the type_caster is able to use to request different behaviour. Currently, AFAICS `convert` is only used for type converters of regular pybind11-registered types; all of the other core type_casters ignore it. We can, however, repurpose it to control internal conversion of converters like Eigen and `array`: most usefully to give callers a way to disable the conversion that would otherwise occur when a `Eigen::Ref<const Eigen::Matrix>` argument is passed a numpy array that requires conversion (either because it has an incompatible stride or the wrong dtype). Specifying a noconvert looks like one of these: m.def("f1", &f, "a"_a.noconvert() = "default"); // Named, default, noconvert m.def("f2", &f, "a"_a.noconvert()); // Named, no default, no converting m.def("f3", &f, py::arg().noconvert()); // Unnamed, no default, no converting (The last part--being able to declare a py::arg without a name--is new: previous py::arg() only accepted named keyword arguments). Such an non-convert argument is then passed `convert = false` by the type caster when loading the argument. Whether this has an effect is up to the type caster itself, but as mentioned above, this would be extremely helpful for the Eigen support to give a nicer way to specify a "no-copy" mode than the custom wrapper in the current PR, and moreover isn't an Eigen-specific hack.
2017-01-23 08:50:00 +00:00
arg_v arg::operator=(T &&value) const { return {std::move(*this), std::forward<T>(value)}; }
Make keyword argument hold a py::object instead of T* With this change arg_t is no longer a template, but it must remain so for backward compatibility. Thus, a non-template arg_v is introduced, while a dummy template alias arg_t is there to keep old code from breaking. This can be remove in the next major release. The implementation of arg_v also needed to be placed a little earlier in the headers because it's not a template any more and unpacking_collector needs more than a forward declaration.
2016-09-05 22:49:21 +00:00
Multiple inheritance support
2016-09-11 11:00:40 +00:00
/// Alias for backward compatibility -- to be removed in version 2.0
Make keyword argument hold a py::object instead of T* With this change arg_t is no longer a template, but it must remain so for backward compatibility. Thus, a non-template arg_v is introduced, while a dummy template alias arg_t is there to keep old code from breaking. This can be remove in the next major release. The implementation of arg_v also needed to be placed a little earlier in the headers because it's not a template any more and unpacking_collector needs more than a forward declaration.
2016-09-05 22:49:21 +00:00
template <typename /*unused*/> using arg_t = arg_v;
inline namespace literals {
Automate generation of reference docs with doxygen and breathe (#598) * Make 'any' the default markup role for Sphinx docs * Automate generation of reference docs with doxygen and breathe * Improve reference docs coverage
2017-01-31 15:54:08 +00:00
/** \rst
String literal version of `arg`
\endrst */
Make keyword argument hold a py::object instead of T* With this change arg_t is no longer a template, but it must remain so for backward compatibility. Thus, a non-template arg_v is introduced, while a dummy template alias arg_t is there to keep old code from breaking. This can be remove in the next major release. The implementation of arg_v also needed to be placed a little earlier in the headers because it's not a template any more and unpacking_collector needs more than a forward declaration.
2016-09-05 22:49:21 +00:00
constexpr arg operator"" _a(const char *name, size_t) { return arg(name); }
}
Support keyword arguments and generalized unpacking in C++ A Python function can be called with the syntax: ```python foo(a1, a2, *args, ka=1, kb=2, **kwargs) ``` This commit adds support for the equivalent syntax in C++: ```c++ foo(a1, a2, *args, "ka"_a=1, "kb"_a=2, **kwargs) ``` In addition, generalized unpacking is implemented, as per PEP 448, which allows calls with multiple * and ** unpacking: ```python bar(*args1, 99, *args2, 101, **kwargs1, kz=200, **kwargs2) ``` and ```c++ bar(*args1, 99, *args2, 101, **kwargs1, "kz"_a=200, **kwargs2) ```
2016-08-29 01:05:42 +00:00
NAMESPACE_BEGIN(detail)
Split up tuple caster and function argument loader This is needed in order to allow the tuple caster to accept any sequence while keeping the argument loader fast. There is also very little overlap between the two classes which makes the separation clean. It’s also good practice not to have completely new functionality in a specialization.
2016-11-27 17:19:34 +00:00
Use std::type_info::name() for type lookups outside stdlibc++ Using `std::type_info::operator==` fails under libc++ because the .so is loaded with RTLD_LOCAL. libc++ considers types under such .sos distinct, and so comparing typeid() values directly isn't going to work. This adds a custom hasher and equality class for the type lookup maps when not under stdlibc++, and adds a `detail::same_type` function to perform the equality test. It also converts a few pointer arguments to const lvalue references, particularly since doing the pointer comparison wasn't technically valid to being with (though in practice, appeared to work everywhere). This fixes #912.
2017-06-21 17:38:10 +00:00
// forward declaration (definition in attr.h)
Add support for positional args with args/kwargs This commit rewrites the function dispatcher code to support mixing regular arguments with py::args/py::kwargs arguments. It also simplifies the argument loader noticeably as it no longer has to worry about args/kwargs: all of that is now sorted out in the dispatcher, which now simply appends a tuple/dict if the function takes py::args/py::kwargs, then passes all the arguments in a vector. When the argument loader hit a py::args or py::kwargs, it doesn't do anything special: it just calls the appropriate type_caster just like it does for any other argument (thus removing the previous special cases for args/kwargs). Switching to passing arguments in a single std::vector instead of a pair of tuples also makes things simpler, both in the dispatch and the argument_loader: since this argument list is strictly pybind-internal (i.e. it never goes to Python) we have no particular reason to use a Python tuple here. Some (intentional) restrictions: - you may not bind a function that has args/kwargs somewhere other than the end (this somewhat matches Python, and keeps the dispatch code a little cleaner by being able to not worry about where to inject the args/kwargs in the argument list). - If you specify an argument both positionally and via a keyword argument, you get a TypeError alerting you to this (as you do in Python).
2017-01-22 04:42:14 +00:00
struct function_record;
Add support for non-converting arguments This adds support for controlling the `convert` flag of arguments through the py::arg annotation. This then allows arguments to be flagged as non-converting, which the type_caster is able to use to request different behaviour. Currently, AFAICS `convert` is only used for type converters of regular pybind11-registered types; all of the other core type_casters ignore it. We can, however, repurpose it to control internal conversion of converters like Eigen and `array`: most usefully to give callers a way to disable the conversion that would otherwise occur when a `Eigen::Ref<const Eigen::Matrix>` argument is passed a numpy array that requires conversion (either because it has an incompatible stride or the wrong dtype). Specifying a noconvert looks like one of these: m.def("f1", &f, "a"_a.noconvert() = "default"); // Named, default, noconvert m.def("f2", &f, "a"_a.noconvert()); // Named, no default, no converting m.def("f3", &f, py::arg().noconvert()); // Unnamed, no default, no converting (The last part--being able to declare a py::arg without a name--is new: previous py::arg() only accepted named keyword arguments). Such an non-convert argument is then passed `convert = false` by the type caster when loading the argument. Whether this has an effect is up to the type caster itself, but as mentioned above, this would be extremely helpful for the Eigen support to give a nicer way to specify a "no-copy" mode than the custom wrapper in the current PR, and moreover isn't an Eigen-specific hack.
2017-01-23 08:50:00 +00:00
/// Internal data associated with a single function call
struct function_call {
Fix potential crash when calling an overloaded function (#1327) * Fix potential crash when calling an overloaded function The crash would occur if: - dispatcher() uses two-pass logic (because the target is overloaded and some arguments support conversions) - the first pass (with conversions disabled) doesn't find any matching overload - the second pass does find a matching overload, but its return value can't be converted to Python The code for formatting the error message assumed `it` still pointed to the selected overload, but during the second-pass loop `it` was nullptr. Fix by setting `it` correctly if a second-pass call returns a nullptr `handle`. Add a new test that segfaults without this fix. * Make overload iteration const-correct so we don't have to iterate again on second-pass error * Change test_error_after_conversions dependencies to local classes/variables
2018-09-25 21:55:18 +00:00
function_call(const function_record &f, handle p); // Implementation in attr.h
Add support for non-converting arguments This adds support for controlling the `convert` flag of arguments through the py::arg annotation. This then allows arguments to be flagged as non-converting, which the type_caster is able to use to request different behaviour. Currently, AFAICS `convert` is only used for type converters of regular pybind11-registered types; all of the other core type_casters ignore it. We can, however, repurpose it to control internal conversion of converters like Eigen and `array`: most usefully to give callers a way to disable the conversion that would otherwise occur when a `Eigen::Ref<const Eigen::Matrix>` argument is passed a numpy array that requires conversion (either because it has an incompatible stride or the wrong dtype). Specifying a noconvert looks like one of these: m.def("f1", &f, "a"_a.noconvert() = "default"); // Named, default, noconvert m.def("f2", &f, "a"_a.noconvert()); // Named, no default, no converting m.def("f3", &f, py::arg().noconvert()); // Unnamed, no default, no converting (The last part--being able to declare a py::arg without a name--is new: previous py::arg() only accepted named keyword arguments). Such an non-convert argument is then passed `convert = false` by the type caster when loading the argument. Whether this has an effect is up to the type caster itself, but as mentioned above, this would be extremely helpful for the Eigen support to give a nicer way to specify a "no-copy" mode than the custom wrapper in the current PR, and moreover isn't an Eigen-specific hack.
2017-01-23 08:50:00 +00:00
/// The function data:
const function_record &func;
/// Arguments passed to the function:
std::vector<handle> args;
/// The `convert` value the arguments should be loaded with
std::vector<bool> args_convert;
Fix premature destruction of args/kwargs arguments The `py::args` or `py::kwargs` arguments aren't properly referenced when added to the function_call arguments list: their reference counts drop to zero if the first (non-converting) function call fails, which means they might be cleaned up before the second pass call runs. This commit adds a couple of extra `object`s to the `function_call` where we can stash a reference to them when needed to tie their lifetime to the function_call object's lifetime. (Credit to YannickJadoul for catching and proposing a fix in #1223).
2017-12-23 13:42:32 +00:00
/// Extra references for the optional `py::args` and/or `py::kwargs` arguments (which, if
/// present, are also in `args` but without a reference).
object args_ref, kwargs_ref;
Add support for non-converting arguments This adds support for controlling the `convert` flag of arguments through the py::arg annotation. This then allows arguments to be flagged as non-converting, which the type_caster is able to use to request different behaviour. Currently, AFAICS `convert` is only used for type converters of regular pybind11-registered types; all of the other core type_casters ignore it. We can, however, repurpose it to control internal conversion of converters like Eigen and `array`: most usefully to give callers a way to disable the conversion that would otherwise occur when a `Eigen::Ref<const Eigen::Matrix>` argument is passed a numpy array that requires conversion (either because it has an incompatible stride or the wrong dtype). Specifying a noconvert looks like one of these: m.def("f1", &f, "a"_a.noconvert() = "default"); // Named, default, noconvert m.def("f2", &f, "a"_a.noconvert()); // Named, no default, no converting m.def("f3", &f, py::arg().noconvert()); // Unnamed, no default, no converting (The last part--being able to declare a py::arg without a name--is new: previous py::arg() only accepted named keyword arguments). Such an non-convert argument is then passed `convert = false` by the type caster when loading the argument. Whether this has an effect is up to the type caster itself, but as mentioned above, this would be extremely helpful for the Eigen support to give a nicer way to specify a "no-copy" mode than the custom wrapper in the current PR, and moreover isn't an Eigen-specific hack.
2017-01-23 08:50:00 +00:00
/// The parent, if any
handle parent;
Fix application of keep_alive policy to constructors (regression)
2017-09-04 11:49:19 +00:00
/// If this is a call to an initializer, this argument contains `self`
handle init_self;
Add support for non-converting arguments This adds support for controlling the `convert` flag of arguments through the py::arg annotation. This then allows arguments to be flagged as non-converting, which the type_caster is able to use to request different behaviour. Currently, AFAICS `convert` is only used for type converters of regular pybind11-registered types; all of the other core type_casters ignore it. We can, however, repurpose it to control internal conversion of converters like Eigen and `array`: most usefully to give callers a way to disable the conversion that would otherwise occur when a `Eigen::Ref<const Eigen::Matrix>` argument is passed a numpy array that requires conversion (either because it has an incompatible stride or the wrong dtype). Specifying a noconvert looks like one of these: m.def("f1", &f, "a"_a.noconvert() = "default"); // Named, default, noconvert m.def("f2", &f, "a"_a.noconvert()); // Named, no default, no converting m.def("f3", &f, py::arg().noconvert()); // Unnamed, no default, no converting (The last part--being able to declare a py::arg without a name--is new: previous py::arg() only accepted named keyword arguments). Such an non-convert argument is then passed `convert = false` by the type caster when loading the argument. Whether this has an effect is up to the type caster itself, but as mentioned above, this would be extremely helpful for the Eigen support to give a nicer way to specify a "no-copy" mode than the custom wrapper in the current PR, and moreover isn't an Eigen-specific hack.
2017-01-23 08:50:00 +00:00
};
Split up tuple caster and function argument loader This is needed in order to allow the tuple caster to accept any sequence while keeping the argument loader fast. There is also very little overlap between the two classes which makes the separation clean. It’s also good practice not to have completely new functionality in a specialization.
2016-11-27 17:19:34 +00:00
/// Helper class which loads arguments for C++ functions called from Python
template <typename... Args>
class argument_loader {
Use C++14 index_sequence when possible Newer standard libraries use compiler intrinsics for std::index_sequence which makes it ‘free’. This prevents hitting instantiation limits for recursive templates (-ftemplate-depth).
2016-11-27 19:56:04 +00:00
using indices = make_index_sequence<sizeof...(Args)>;
Split up tuple caster and function argument loader This is needed in order to allow the tuple caster to accept any sequence while keeping the argument loader fast. There is also very little overlap between the two classes which makes the separation clean. It’s also good practice not to have completely new functionality in a specialization.
2016-11-27 17:19:34 +00:00
Use constexpr_first for args/kwargs positional checks
2017-01-23 00:15:12 +00:00
template <typename Arg> using argument_is_args = std::is_same<intrinsic_t<Arg>, args>;
template <typename Arg> using argument_is_kwargs = std::is_same<intrinsic_t<Arg>, kwargs>;
// Get args/kwargs argument positions relative to the end of the argument list:
static constexpr auto args_pos = constexpr_first<argument_is_args, Args...>() - (int) sizeof...(Args),
kwargs_pos = constexpr_first<argument_is_kwargs, Args...>() - (int) sizeof...(Args);
static constexpr bool args_kwargs_are_last = kwargs_pos >= - 1 && args_pos >= kwargs_pos - 1;
static_assert(args_kwargs_are_last, "py::args/py::kwargs are only permitted as the last argument(s) of a function");
Work around gcc 7 ICE Current g++ 7 snapshot fails to compile pybind under -std=c++17 with: ``` $ make [ 3%] Building CXX object tests/CMakeFiles/pybind11_tests.dir/pybind11_tests.cpp.o In file included from /home/jagerman/src/pybind11/tests/pybind11_tests.h:2:0, from /home/jagerman/src/pybind11/tests/pybind11_tests.cpp:10: /home/jagerman/src/pybind11/include/pybind11/pybind11.h: In instantiation of 'pybind11::cpp_function::initialize(Func&&, Return (*)(Args ...), const Extra& ...)::<lambda(pybind11::detail::function_record*, pybind11::handle, pybind11::handle, pybind11::handle)> [with Func = pybind11::cpp_function::cpp_function(Return (Class::*)(Arg ...), const Extra& ...) [with Return = int; Class = ConstructorStats; Arg = {}; Extra = {pybind11::name, pybind11::is_method, pybind11::sibling}]::<lambda(ConstructorStats*)>; Return = int; Args = {ConstructorStats*}; Extra = {pybind11::name, pybind11::is_method, pybind11::sibling}]': /home/jagerman/src/pybind11/include/pybind11/pybind11.h:120:22: required from 'struct pybind11::cpp_function::initialize(Func&&, Return (*)(Args ...), const Extra& ...) [with Func = pybind11::cpp_function::cpp_function(Return (Class::*)(Arg ...), const Extra& ...) [with Return = int; Class = ConstructorStats; Arg = {}; Extra = {pybind11::name, pybind11::is_method, pybind11::sibling}]::<lambda(ConstructorStats*)>; Return = int; Args = {ConstructorStats*}; Extra = {pybind11::name, pybind11::is_method, pybind11::sibling}]::<lambda(struct pybind11::detail::function_record*, class pybind11::handle, class pybind11::handle, class pybind11::handle)>' /home/jagerman/src/pybind11/include/pybind11/pybind11.h:120:19: required from 'void pybind11::cpp_function::initialize(Func&&, Return (*)(Args ...), const Extra& ...) [with Func = pybind11::cpp_function::cpp_function(Return (Class::*)(Arg ...), const Extra& ...) [with Return = int; Class = ConstructorStats; Arg = {}; Extra = {pybind11::name, pybind11::is_method, pybind11::sibling}]::<lambda(ConstructorStats*)>; Return = int; Args = {ConstructorStats*}; Extra = {pybind11::name, pybind11::is_method, pybind11::sibling}]' /home/jagerman/src/pybind11/include/pybind11/pybind11.h:62:9: required from 'pybind11::cpp_function::cpp_function(Return (Class::*)(Arg ...), const Extra& ...) [with Return = int; Class = ConstructorStats; Arg = {}; Extra = {pybind11::name, pybind11::is_method, pybind11::sibling}]' /home/jagerman/src/pybind11/include/pybind11/pybind11.h:984:22: required from 'pybind11::class_<type_, options>& pybind11::class_<type_, options>::def(const char*, Func&&, const Extra& ...) [with Func = int (ConstructorStats::*)(); Extra = {}; type_ = ConstructorStats; options = {}]' /home/jagerman/src/pybind11/tests/pybind11_tests.cpp:24:47: required from here /home/jagerman/src/pybind11/include/pybind11/pybind11.h:147:9: sorry, unimplemented: unexpected AST of kind cleanup_stmt }; ^ /home/jagerman/src/pybind11/include/pybind11/pybind11.h:147:9: internal compiler error: in potential_constant_expression_1, at cp/constexpr.c:5593 0x84c52a potential_constant_expression_1 ../../src/gcc/cp/constexpr.c:5593 0x84c3c0 potential_constant_expression_1 ../../src/gcc/cp/constexpr.c:5154 0x645511 finish_function(int) ../../src/gcc/cp/decl.c:15527 0x66e80b instantiate_decl(tree_node*, int, bool) ../../src/gcc/cp/pt.c:22558 0x6b61e2 instantiate_class_template_1 ../../src/gcc/cp/pt.c:10444 0x6b61e2 instantiate_class_template(tree_node*) ../../src/gcc/cp/pt.c:10514 0x75a676 complete_type(tree_node*) ../../src/gcc/cp/typeck.c:133 0x67d5a4 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../src/gcc/cp/pt.c:17516 0x67ca19 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../src/gcc/cp/pt.c:16655 0x672cce tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../src/gcc/cp/pt.c:16140 0x6713dc tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../src/gcc/cp/pt.c:15408 0x671915 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../src/gcc/cp/pt.c:15394 0x671fc0 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../src/gcc/cp/pt.c:15618 0x66e97f tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../src/gcc/cp/pt.c:15379 0x66e97f instantiate_decl(tree_node*, int, bool) ../../src/gcc/cp/pt.c:22536 0x6ba0cb instantiate_pending_templates(int) ../../src/gcc/cp/pt.c:22653 0x6fd7f8 c_parse_final_cleanups() ../../src/gcc/cp/decl2.c:4512 ``` which looks a lot like https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77545. The error seems to be that it gets confused about the `std::tuple<...> value` in argument_loader: it is apparently not being initialized properly. Adding a default constructor with an explicit default-initialization of `value` works around the problem.
2016-12-14 00:11:36 +00:00
Add support for positional args with args/kwargs This commit rewrites the function dispatcher code to support mixing regular arguments with py::args/py::kwargs arguments. It also simplifies the argument loader noticeably as it no longer has to worry about args/kwargs: all of that is now sorted out in the dispatcher, which now simply appends a tuple/dict if the function takes py::args/py::kwargs, then passes all the arguments in a vector. When the argument loader hit a py::args or py::kwargs, it doesn't do anything special: it just calls the appropriate type_caster just like it does for any other argument (thus removing the previous special cases for args/kwargs). Switching to passing arguments in a single std::vector instead of a pair of tuples also makes things simpler, both in the dispatch and the argument_loader: since this argument list is strictly pybind-internal (i.e. it never goes to Python) we have no particular reason to use a Python tuple here. Some (intentional) restrictions: - you may not bind a function that has args/kwargs somewhere other than the end (this somewhat matches Python, and keeps the dispatch code a little cleaner by being able to not worry about where to inject the args/kwargs in the argument list). - If you specify an argument both positionally and via a keyword argument, you get a TypeError alerting you to this (as you do in Python).
2017-01-22 04:42:14 +00:00
public:
Use constexpr_first for args/kwargs positional checks
2017-01-23 00:15:12 +00:00
static constexpr bool has_kwargs = kwargs_pos < 0;
static constexpr bool has_args = args_pos < 0;
Split up tuple caster and function argument loader This is needed in order to allow the tuple caster to accept any sequence while keeping the argument loader fast. There is also very little overlap between the two classes which makes the separation clean. It’s also good practice not to have completely new functionality in a specialization.
2016-11-27 17:19:34 +00:00
Simplify function signature annotation and parsing `type_descr` is now applied only to the final signature so that it only marks the argument types, but not nested types (e.g. for tuples) or return types.
2017-08-31 12:38:23 +00:00
static constexpr auto arg_names = concat(type_descr(make_caster<Args>::name)...);
Split up tuple caster and function argument loader This is needed in order to allow the tuple caster to accept any sequence while keeping the argument loader fast. There is also very little overlap between the two classes which makes the separation clean. It’s also good practice not to have completely new functionality in a specialization.
2016-11-27 17:19:34 +00:00
Add support for non-converting arguments This adds support for controlling the `convert` flag of arguments through the py::arg annotation. This then allows arguments to be flagged as non-converting, which the type_caster is able to use to request different behaviour. Currently, AFAICS `convert` is only used for type converters of regular pybind11-registered types; all of the other core type_casters ignore it. We can, however, repurpose it to control internal conversion of converters like Eigen and `array`: most usefully to give callers a way to disable the conversion that would otherwise occur when a `Eigen::Ref<const Eigen::Matrix>` argument is passed a numpy array that requires conversion (either because it has an incompatible stride or the wrong dtype). Specifying a noconvert looks like one of these: m.def("f1", &f, "a"_a.noconvert() = "default"); // Named, default, noconvert m.def("f2", &f, "a"_a.noconvert()); // Named, no default, no converting m.def("f3", &f, py::arg().noconvert()); // Unnamed, no default, no converting (The last part--being able to declare a py::arg without a name--is new: previous py::arg() only accepted named keyword arguments). Such an non-convert argument is then passed `convert = false` by the type caster when loading the argument. Whether this has an effect is up to the type caster itself, but as mentioned above, this would be extremely helpful for the Eigen support to give a nicer way to specify a "no-copy" mode than the custom wrapper in the current PR, and moreover isn't an Eigen-specific hack.
2017-01-23 08:50:00 +00:00
bool load_args(function_call &call) {
return load_impl_sequence(call, indices{});
Split up tuple caster and function argument loader This is needed in order to allow the tuple caster to accept any sequence while keeping the argument loader fast. There is also very little overlap between the two classes which makes the separation clean. It’s also good practice not to have completely new functionality in a specialization.
2016-11-27 17:19:34 +00:00
}
Add a scope guard call policy ```c++ m.def("foo", foo, py::call_guard<T>()); ``` is equivalent to: ```c++ m.def("foo", [](args...) { T scope_guard; return foo(args...); // forwarded arguments }); ```
2017-03-16 10:22:26 +00:00
template <typename Return, typename Guard, typename Func>
Add movable cast support to type casters This commit allows type_casters to allow their local values to be moved away, rather than copied, when the type caster instance itself is an rvalue. This only applies (automatically) to type casters using PYBIND11_TYPE_CASTER; the generic type type casters don't own their own pointer, and various value casters (e.g. std::string, std::pair, arithmetic types) already cast to an rvalue (i.e. they return by value). This updates various calling code to attempt to get a movable value whenever the value is itself coming from a type caster about to be destroyed: for example, when constructing an std::pair or various stl.h containers. For types that don't support value moving, the cast_op falls back to an lvalue cast. There wasn't an obvious place to add the tests, so I added them to test_copy_move_policies, but also renamed it to drop the _policies as it now tests more than just policies.
2017-05-14 19:57:26 +00:00
enable_if_t<!std::is_void<Return>::value, Return> call(Func &&f) && {
return std::move(*this).template call_impl<Return>(std::forward<Func>(f), indices{}, Guard{});
Split up tuple caster and function argument loader This is needed in order to allow the tuple caster to accept any sequence while keeping the argument loader fast. There is also very little overlap between the two classes which makes the separation clean. It’s also good practice not to have completely new functionality in a specialization.
2016-11-27 17:19:34 +00:00
}
Add a scope guard call policy ```c++ m.def("foo", foo, py::call_guard<T>()); ``` is equivalent to: ```c++ m.def("foo", [](args...) { T scope_guard; return foo(args...); // forwarded arguments }); ```
2017-03-16 10:22:26 +00:00
template <typename Return, typename Guard, typename Func>
Add movable cast support to type casters This commit allows type_casters to allow their local values to be moved away, rather than copied, when the type caster instance itself is an rvalue. This only applies (automatically) to type casters using PYBIND11_TYPE_CASTER; the generic type type casters don't own their own pointer, and various value casters (e.g. std::string, std::pair, arithmetic types) already cast to an rvalue (i.e. they return by value). This updates various calling code to attempt to get a movable value whenever the value is itself coming from a type caster about to be destroyed: for example, when constructing an std::pair or various stl.h containers. For types that don't support value moving, the cast_op falls back to an lvalue cast. There wasn't an obvious place to add the tests, so I added them to test_copy_move_policies, but also renamed it to drop the _policies as it now tests more than just policies.
2017-05-14 19:57:26 +00:00
enable_if_t<std::is_void<Return>::value, void_type> call(Func &&f) && {
std::move(*this).template call_impl<Return>(std::forward<Func>(f), indices{}, Guard{});
Split up tuple caster and function argument loader This is needed in order to allow the tuple caster to accept any sequence while keeping the argument loader fast. There is also very little overlap between the two classes which makes the separation clean. It’s also good practice not to have completely new functionality in a specialization.
2016-11-27 17:19:34 +00:00
return void_type();
}
private:
Add support for non-converting arguments This adds support for controlling the `convert` flag of arguments through the py::arg annotation. This then allows arguments to be flagged as non-converting, which the type_caster is able to use to request different behaviour. Currently, AFAICS `convert` is only used for type converters of regular pybind11-registered types; all of the other core type_casters ignore it. We can, however, repurpose it to control internal conversion of converters like Eigen and `array`: most usefully to give callers a way to disable the conversion that would otherwise occur when a `Eigen::Ref<const Eigen::Matrix>` argument is passed a numpy array that requires conversion (either because it has an incompatible stride or the wrong dtype). Specifying a noconvert looks like one of these: m.def("f1", &f, "a"_a.noconvert() = "default"); // Named, default, noconvert m.def("f2", &f, "a"_a.noconvert()); // Named, no default, no converting m.def("f3", &f, py::arg().noconvert()); // Unnamed, no default, no converting (The last part--being able to declare a py::arg without a name--is new: previous py::arg() only accepted named keyword arguments). Such an non-convert argument is then passed `convert = false` by the type caster when loading the argument. Whether this has an effect is up to the type caster itself, but as mentioned above, this would be extremely helpful for the Eigen support to give a nicer way to specify a "no-copy" mode than the custom wrapper in the current PR, and moreover isn't an Eigen-specific hack.
2017-01-23 08:50:00 +00:00
static bool load_impl_sequence(function_call &, index_sequence<>) { return true; }
Split up tuple caster and function argument loader This is needed in order to allow the tuple caster to accept any sequence while keeping the argument loader fast. There is also very little overlap between the two classes which makes the separation clean. It’s also good practice not to have completely new functionality in a specialization.
2016-11-27 17:19:34 +00:00
template <size_t... Is>
Add support for non-converting arguments This adds support for controlling the `convert` flag of arguments through the py::arg annotation. This then allows arguments to be flagged as non-converting, which the type_caster is able to use to request different behaviour. Currently, AFAICS `convert` is only used for type converters of regular pybind11-registered types; all of the other core type_casters ignore it. We can, however, repurpose it to control internal conversion of converters like Eigen and `array`: most usefully to give callers a way to disable the conversion that would otherwise occur when a `Eigen::Ref<const Eigen::Matrix>` argument is passed a numpy array that requires conversion (either because it has an incompatible stride or the wrong dtype). Specifying a noconvert looks like one of these: m.def("f1", &f, "a"_a.noconvert() = "default"); // Named, default, noconvert m.def("f2", &f, "a"_a.noconvert()); // Named, no default, no converting m.def("f3", &f, py::arg().noconvert()); // Unnamed, no default, no converting (The last part--being able to declare a py::arg without a name--is new: previous py::arg() only accepted named keyword arguments). Such an non-convert argument is then passed `convert = false` by the type caster when loading the argument. Whether this has an effect is up to the type caster itself, but as mentioned above, this would be extremely helpful for the Eigen support to give a nicer way to specify a "no-copy" mode than the custom wrapper in the current PR, and moreover isn't an Eigen-specific hack.
2017-01-23 08:50:00 +00:00
bool load_impl_sequence(function_call &call, index_sequence<Is...>) {
Add movable cast support to type casters This commit allows type_casters to allow their local values to be moved away, rather than copied, when the type caster instance itself is an rvalue. This only applies (automatically) to type casters using PYBIND11_TYPE_CASTER; the generic type type casters don't own their own pointer, and various value casters (e.g. std::string, std::pair, arithmetic types) already cast to an rvalue (i.e. they return by value). This updates various calling code to attempt to get a movable value whenever the value is itself coming from a type caster about to be destroyed: for example, when constructing an std::pair or various stl.h containers. For types that don't support value moving, the cast_op falls back to an lvalue cast. There wasn't an obvious place to add the tests, so I added them to test_copy_move_policies, but also renamed it to drop the _policies as it now tests more than just policies.
2017-05-14 19:57:26 +00:00
for (bool r : {std::get<Is>(argcasters).load(call.args[Is], call.args_convert[Is])...})
Split up tuple caster and function argument loader This is needed in order to allow the tuple caster to accept any sequence while keeping the argument loader fast. There is also very little overlap between the two classes which makes the separation clean. It’s also good practice not to have completely new functionality in a specialization.
2016-11-27 17:19:34 +00:00
if (!r)
return false;
return true;
}
Add a scope guard call policy ```c++ m.def("foo", foo, py::call_guard<T>()); ``` is equivalent to: ```c++ m.def("foo", [](args...) { T scope_guard; return foo(args...); // forwarded arguments }); ```
2017-03-16 10:22:26 +00:00
template <typename Return, typename Func, size_t... Is, typename Guard>
Return call_impl(Func &&f, index_sequence<Is...>, Guard &&) {
Add movable cast support to type casters This commit allows type_casters to allow their local values to be moved away, rather than copied, when the type caster instance itself is an rvalue. This only applies (automatically) to type casters using PYBIND11_TYPE_CASTER; the generic type type casters don't own their own pointer, and various value casters (e.g. std::string, std::pair, arithmetic types) already cast to an rvalue (i.e. they return by value). This updates various calling code to attempt to get a movable value whenever the value is itself coming from a type caster about to be destroyed: for example, when constructing an std::pair or various stl.h containers. For types that don't support value moving, the cast_op falls back to an lvalue cast. There wasn't an obvious place to add the tests, so I added them to test_copy_move_policies, but also renamed it to drop the _policies as it now tests more than just policies.
2017-05-14 19:57:26 +00:00
return std::forward<Func>(f)(cast_op<Args>(std::move(std::get<Is>(argcasters)))...);
Split up tuple caster and function argument loader This is needed in order to allow the tuple caster to accept any sequence while keeping the argument loader fast. There is also very little overlap between the two classes which makes the separation clean. It’s also good practice not to have completely new functionality in a specialization.
2016-11-27 17:19:34 +00:00
}
Add movable cast support to type casters This commit allows type_casters to allow their local values to be moved away, rather than copied, when the type caster instance itself is an rvalue. This only applies (automatically) to type casters using PYBIND11_TYPE_CASTER; the generic type type casters don't own their own pointer, and various value casters (e.g. std::string, std::pair, arithmetic types) already cast to an rvalue (i.e. they return by value). This updates various calling code to attempt to get a movable value whenever the value is itself coming from a type caster about to be destroyed: for example, when constructing an std::pair or various stl.h containers. For types that don't support value moving, the cast_op falls back to an lvalue cast. There wasn't an obvious place to add the tests, so I added them to test_copy_move_policies, but also renamed it to drop the _policies as it now tests more than just policies.
2017-05-14 19:57:26 +00:00
std::tuple<make_caster<Args>...> argcasters;
Split up tuple caster and function argument loader This is needed in order to allow the tuple caster to accept any sequence while keeping the argument loader fast. There is also very little overlap between the two classes which makes the separation clean. It’s also good practice not to have completely new functionality in a specialization.
2016-11-27 17:19:34 +00:00
};
Support keyword arguments and generalized unpacking in C++ A Python function can be called with the syntax: ```python foo(a1, a2, *args, ka=1, kb=2, **kwargs) ``` This commit adds support for the equivalent syntax in C++: ```c++ foo(a1, a2, *args, "ka"_a=1, "kb"_a=2, **kwargs) ``` In addition, generalized unpacking is implemented, as per PEP 448, which allows calls with multiple * and ** unpacking: ```python bar(*args1, 99, *args2, 101, **kwargs1, kz=200, **kwargs2) ``` and ```c++ bar(*args1, 99, *args2, 101, **kwargs1, "kz"_a=200, **kwargs2) ```
2016-08-29 01:05:42 +00:00
/// Helper class which collects only positional arguments for a Python function call.
/// A fancier version below can collect any argument, but this one is optimal for simple calls.
template <return_value_policy policy>
class simple_collector {
public:
template <typename... Ts>
Disable most implicit conversion constructors We have various classes that have non-explicit constructors that accept a single argument, which is implicitly making them implicitly convertible from the argument. In a few cases, this is desirable (e.g. implicit conversion of std::string to py::str, or conversion of double to py::float_); in many others, however, it is unintended (e.g. implicit conversion of size_t to some pre-declared py::array_t<T> type). This disables most of the unwanted implicit conversions by marking them `explicit`, and comments the ones that are deliberately left implicit.
2016-10-16 20:27:42 +00:00
explicit simple_collector(Ts &&...values)
Support keyword arguments and generalized unpacking in C++ A Python function can be called with the syntax: ```python foo(a1, a2, *args, ka=1, kb=2, **kwargs) ``` This commit adds support for the equivalent syntax in C++: ```c++ foo(a1, a2, *args, "ka"_a=1, "kb"_a=2, **kwargs) ``` In addition, generalized unpacking is implemented, as per PEP 448, which allows calls with multiple * and ** unpacking: ```python bar(*args1, 99, *args2, 101, **kwargs1, kz=200, **kwargs2) ``` and ```c++ bar(*args1, 99, *args2, 101, **kwargs1, "kz"_a=200, **kwargs2) ```
2016-08-29 01:05:42 +00:00
: m_args(pybind11::make_tuple<policy>(std::forward<Ts>(values)...)) { }
const tuple &args() const & { return m_args; }
dict kwargs() const { return {}; }
tuple args() && { return std::move(m_args); }
/// Call a Python function and pass the collected arguments
object call(PyObject *ptr) const {
Add py::reinterpret_borrow<T>()/steal<T>() for low-level unchecked casts The pytype converting constructors are convenient and safe for user code, but for library internals the additional type checks and possible conversions are sometimes not desired. `reinterpret_borrow<T>()` and `reinterpret_steal<T>()` serve as the low-level unsafe counterparts of `cast<T>()`. This deprecates the `object(handle, bool)` constructor. Renamed `borrowed` parameter to `is_borrowed` to avoid shadowing warnings on MSVC.
2016-10-28 01:08:15 +00:00
PyObject *result = PyObject_CallObject(ptr, m_args.ptr());
Support keyword arguments and generalized unpacking in C++ A Python function can be called with the syntax: ```python foo(a1, a2, *args, ka=1, kb=2, **kwargs) ``` This commit adds support for the equivalent syntax in C++: ```c++ foo(a1, a2, *args, "ka"_a=1, "kb"_a=2, **kwargs) ``` In addition, generalized unpacking is implemented, as per PEP 448, which allows calls with multiple * and ** unpacking: ```python bar(*args1, 99, *args2, 101, **kwargs1, kz=200, **kwargs2) ``` and ```c++ bar(*args1, 99, *args2, 101, **kwargs1, "kz"_a=200, **kwargs2) ```
2016-08-29 01:05:42 +00:00
if (!result)
throw error_already_set();
Add py::reinterpret_borrow<T>()/steal<T>() for low-level unchecked casts The pytype converting constructors are convenient and safe for user code, but for library internals the additional type checks and possible conversions are sometimes not desired. `reinterpret_borrow<T>()` and `reinterpret_steal<T>()` serve as the low-level unsafe counterparts of `cast<T>()`. This deprecates the `object(handle, bool)` constructor. Renamed `borrowed` parameter to `is_borrowed` to avoid shadowing warnings on MSVC.
2016-10-28 01:08:15 +00:00
return reinterpret_steal<object>(result);
Support keyword arguments and generalized unpacking in C++ A Python function can be called with the syntax: ```python foo(a1, a2, *args, ka=1, kb=2, **kwargs) ``` This commit adds support for the equivalent syntax in C++: ```c++ foo(a1, a2, *args, "ka"_a=1, "kb"_a=2, **kwargs) ``` In addition, generalized unpacking is implemented, as per PEP 448, which allows calls with multiple * and ** unpacking: ```python bar(*args1, 99, *args2, 101, **kwargs1, kz=200, **kwargs2) ``` and ```c++ bar(*args1, 99, *args2, 101, **kwargs1, "kz"_a=200, **kwargs2) ```
2016-08-29 01:05:42 +00:00
}
private:
tuple m_args;
};
/// Helper class which collects positional, keyword, * and ** arguments for a Python function call
template <return_value_policy policy>
class unpacking_collector {
public:
template <typename... Ts>
Disable most implicit conversion constructors We have various classes that have non-explicit constructors that accept a single argument, which is implicitly making them implicitly convertible from the argument. In a few cases, this is desirable (e.g. implicit conversion of std::string to py::str, or conversion of double to py::float_); in many others, however, it is unintended (e.g. implicit conversion of size_t to some pre-declared py::array_t<T> type). This disables most of the unwanted implicit conversions by marking them `explicit`, and comments the ones that are deliberately left implicit.
2016-10-16 20:27:42 +00:00
explicit unpacking_collector(Ts &&...values) {
Support keyword arguments and generalized unpacking in C++ A Python function can be called with the syntax: ```python foo(a1, a2, *args, ka=1, kb=2, **kwargs) ``` This commit adds support for the equivalent syntax in C++: ```c++ foo(a1, a2, *args, "ka"_a=1, "kb"_a=2, **kwargs) ``` In addition, generalized unpacking is implemented, as per PEP 448, which allows calls with multiple * and ** unpacking: ```python bar(*args1, 99, *args2, 101, **kwargs1, kz=200, **kwargs2) ``` and ```c++ bar(*args1, 99, *args2, 101, **kwargs1, "kz"_a=200, **kwargs2) ```
2016-08-29 01:05:42 +00:00
// Tuples aren't (easily) resizable so a list is needed for collection,
// but the actual function call strictly requires a tuple.
auto args_list = list();
int _[] = { 0, (process(args_list, std::forward<Ts>(values)), 0)... };
ignore_unused(_);
Add default and converting constructors for all concrete Python types * Deprecate the `py::object::str()` member function since `py::str(obj)` is now equivalent and preferred * Make `py::repr()` a free function * Make sure obj.cast<T>() works as expected when T is a Python type `obj.cast<T>()` should be the same as `T(obj)`, i.e. it should convert the given object to a different Python type. However, `obj.cast<T>()` usually calls `type_caster::load()` which only checks the type without doing any actual conversion. That causes a very unexpected `cast_error`. This commit makes it so that `obj.cast<T>()` and `T(obj)` are the same when T is a Python type. * Simplify pytypes converting constructor implementation It's not necessary to maintain a full set of converting constructors and assignment operators + const& and &&. A single converting const& constructor will work and there is no impact on binary size. On the other hand, the conversion functions can be significantly simplified.
2016-10-25 20:12:39 +00:00
m_args = std::move(args_list);
Support keyword arguments and generalized unpacking in C++ A Python function can be called with the syntax: ```python foo(a1, a2, *args, ka=1, kb=2, **kwargs) ``` This commit adds support for the equivalent syntax in C++: ```c++ foo(a1, a2, *args, "ka"_a=1, "kb"_a=2, **kwargs) ``` In addition, generalized unpacking is implemented, as per PEP 448, which allows calls with multiple * and ** unpacking: ```python bar(*args1, 99, *args2, 101, **kwargs1, kz=200, **kwargs2) ``` and ```c++ bar(*args1, 99, *args2, 101, **kwargs1, "kz"_a=200, **kwargs2) ```
2016-08-29 01:05:42 +00:00
}
const tuple &args() const & { return m_args; }
const dict &kwargs() const & { return m_kwargs; }
tuple args() && { return std::move(m_args); }
dict kwargs() && { return std::move(m_kwargs); }
/// Call a Python function and pass the collected arguments
object call(PyObject *ptr) const {
Add py::reinterpret_borrow<T>()/steal<T>() for low-level unchecked casts The pytype converting constructors are convenient and safe for user code, but for library internals the additional type checks and possible conversions are sometimes not desired. `reinterpret_borrow<T>()` and `reinterpret_steal<T>()` serve as the low-level unsafe counterparts of `cast<T>()`. This deprecates the `object(handle, bool)` constructor. Renamed `borrowed` parameter to `is_borrowed` to avoid shadowing warnings on MSVC.
2016-10-28 01:08:15 +00:00
PyObject *result = PyObject_Call(ptr, m_args.ptr(), m_kwargs.ptr());
Support keyword arguments and generalized unpacking in C++ A Python function can be called with the syntax: ```python foo(a1, a2, *args, ka=1, kb=2, **kwargs) ``` This commit adds support for the equivalent syntax in C++: ```c++ foo(a1, a2, *args, "ka"_a=1, "kb"_a=2, **kwargs) ``` In addition, generalized unpacking is implemented, as per PEP 448, which allows calls with multiple * and ** unpacking: ```python bar(*args1, 99, *args2, 101, **kwargs1, kz=200, **kwargs2) ``` and ```c++ bar(*args1, 99, *args2, 101, **kwargs1, "kz"_a=200, **kwargs2) ```
2016-08-29 01:05:42 +00:00
if (!result)
throw error_already_set();
Add py::reinterpret_borrow<T>()/steal<T>() for low-level unchecked casts The pytype converting constructors are convenient and safe for user code, but for library internals the additional type checks and possible conversions are sometimes not desired. `reinterpret_borrow<T>()` and `reinterpret_steal<T>()` serve as the low-level unsafe counterparts of `cast<T>()`. This deprecates the `object(handle, bool)` constructor. Renamed `borrowed` parameter to `is_borrowed` to avoid shadowing warnings on MSVC.
2016-10-28 01:08:15 +00:00
return reinterpret_steal<object>(result);
Support keyword arguments and generalized unpacking in C++ A Python function can be called with the syntax: ```python foo(a1, a2, *args, ka=1, kb=2, **kwargs) ``` This commit adds support for the equivalent syntax in C++: ```c++ foo(a1, a2, *args, "ka"_a=1, "kb"_a=2, **kwargs) ``` In addition, generalized unpacking is implemented, as per PEP 448, which allows calls with multiple * and ** unpacking: ```python bar(*args1, 99, *args2, 101, **kwargs1, kz=200, **kwargs2) ``` and ```c++ bar(*args1, 99, *args2, 101, **kwargs1, "kz"_a=200, **kwargs2) ```
2016-08-29 01:05:42 +00:00
}
private:
template <typename T>
void process(list &args_list, T &&x) {
Add py::reinterpret_borrow<T>()/steal<T>() for low-level unchecked casts The pytype converting constructors are convenient and safe for user code, but for library internals the additional type checks and possible conversions are sometimes not desired. `reinterpret_borrow<T>()` and `reinterpret_steal<T>()` serve as the low-level unsafe counterparts of `cast<T>()`. This deprecates the `object(handle, bool)` constructor. Renamed `borrowed` parameter to `is_borrowed` to avoid shadowing warnings on MSVC.
2016-10-28 01:08:15 +00:00
auto o = reinterpret_steal<object>(detail::make_caster<T>::cast(std::forward<T>(x), policy, {}));
Support keyword arguments and generalized unpacking in C++ A Python function can be called with the syntax: ```python foo(a1, a2, *args, ka=1, kb=2, **kwargs) ``` This commit adds support for the equivalent syntax in C++: ```c++ foo(a1, a2, *args, "ka"_a=1, "kb"_a=2, **kwargs) ``` In addition, generalized unpacking is implemented, as per PEP 448, which allows calls with multiple * and ** unpacking: ```python bar(*args1, 99, *args2, 101, **kwargs1, kz=200, **kwargs2) ``` and ```c++ bar(*args1, 99, *args2, 101, **kwargs1, "kz"_a=200, **kwargs2) ```
2016-08-29 01:05:42 +00:00
if (!o) {
#if defined(NDEBUG)
argument_cast_error();
#else
argument_cast_error(std::to_string(args_list.size()), type_id<T>());
#endif
}
args_list.append(o);
}
void process(list &args_list, detail::args_proxy ap) {
unpacking_collector: allow nullptr-valued kwargs argument This fixes an issue that can arise when forwarding (*args, **kwargs) captured from a pybind11-bound function call to another Python function. When the initial function call includes no keyword arguments, the py::kwargs field is set to nullptr and causes a crash later on.
2016-10-08 13:30:00 +00:00
for (const auto &a : ap)
Extend attribute and item accessor interface using object_api
2016-09-08 15:02:04 +00:00
args_list.append(a);
Support keyword arguments and generalized unpacking in C++ A Python function can be called with the syntax: ```python foo(a1, a2, *args, ka=1, kb=2, **kwargs) ``` This commit adds support for the equivalent syntax in C++: ```c++ foo(a1, a2, *args, "ka"_a=1, "kb"_a=2, **kwargs) ``` In addition, generalized unpacking is implemented, as per PEP 448, which allows calls with multiple * and ** unpacking: ```python bar(*args1, 99, *args2, 101, **kwargs1, kz=200, **kwargs2) ``` and ```c++ bar(*args1, 99, *args2, 101, **kwargs1, "kz"_a=200, **kwargs2) ```
2016-08-29 01:05:42 +00:00
}
Make keyword argument hold a py::object instead of T* With this change arg_t is no longer a template, but it must remain so for backward compatibility. Thus, a non-template arg_v is introduced, while a dummy template alias arg_t is there to keep old code from breaking. This can be remove in the next major release. The implementation of arg_v also needed to be placed a little earlier in the headers because it's not a template any more and unpacking_collector needs more than a forward declaration.
2016-09-05 22:49:21 +00:00
void process(list &/*args_list*/, arg_v a) {
Add support for non-converting arguments This adds support for controlling the `convert` flag of arguments through the py::arg annotation. This then allows arguments to be flagged as non-converting, which the type_caster is able to use to request different behaviour. Currently, AFAICS `convert` is only used for type converters of regular pybind11-registered types; all of the other core type_casters ignore it. We can, however, repurpose it to control internal conversion of converters like Eigen and `array`: most usefully to give callers a way to disable the conversion that would otherwise occur when a `Eigen::Ref<const Eigen::Matrix>` argument is passed a numpy array that requires conversion (either because it has an incompatible stride or the wrong dtype). Specifying a noconvert looks like one of these: m.def("f1", &f, "a"_a.noconvert() = "default"); // Named, default, noconvert m.def("f2", &f, "a"_a.noconvert()); // Named, no default, no converting m.def("f3", &f, py::arg().noconvert()); // Unnamed, no default, no converting (The last part--being able to declare a py::arg without a name--is new: previous py::arg() only accepted named keyword arguments). Such an non-convert argument is then passed `convert = false` by the type caster when loading the argument. Whether this has an effect is up to the type caster itself, but as mentioned above, this would be extremely helpful for the Eigen support to give a nicer way to specify a "no-copy" mode than the custom wrapper in the current PR, and moreover isn't an Eigen-specific hack.
2017-01-23 08:50:00 +00:00
if (!a.name)
#if defined(NDEBUG)
nameless_argument_error();
#else
nameless_argument_error(a.type);
#endif
Make attr and item accessors throw on error instead of returning nullptr This also adds the `hasattr` and `getattr` functions which are needed with the new attribute behavior. The new functions behave exactly like their Python counterparts. Similarly `object` gets a `contains` method which calls `__contains__`, i.e. it's the same as the `in` keyword in Python.
2016-09-20 23:06:32 +00:00
if (m_kwargs.contains(a.name)) {
Support keyword arguments and generalized unpacking in C++ A Python function can be called with the syntax: ```python foo(a1, a2, *args, ka=1, kb=2, **kwargs) ``` This commit adds support for the equivalent syntax in C++: ```c++ foo(a1, a2, *args, "ka"_a=1, "kb"_a=2, **kwargs) ``` In addition, generalized unpacking is implemented, as per PEP 448, which allows calls with multiple * and ** unpacking: ```python bar(*args1, 99, *args2, 101, **kwargs1, kz=200, **kwargs2) ``` and ```c++ bar(*args1, 99, *args2, 101, **kwargs1, "kz"_a=200, **kwargs2) ```
2016-08-29 01:05:42 +00:00
#if defined(NDEBUG)
multiple_values_error();
#else
multiple_values_error(a.name);
#endif
}
Make keyword argument hold a py::object instead of T* With this change arg_t is no longer a template, but it must remain so for backward compatibility. Thus, a non-template arg_v is introduced, while a dummy template alias arg_t is there to keep old code from breaking. This can be remove in the next major release. The implementation of arg_v also needed to be placed a little earlier in the headers because it's not a template any more and unpacking_collector needs more than a forward declaration.
2016-09-05 22:49:21 +00:00
if (!a.value) {
Support keyword arguments and generalized unpacking in C++ A Python function can be called with the syntax: ```python foo(a1, a2, *args, ka=1, kb=2, **kwargs) ``` This commit adds support for the equivalent syntax in C++: ```c++ foo(a1, a2, *args, "ka"_a=1, "kb"_a=2, **kwargs) ``` In addition, generalized unpacking is implemented, as per PEP 448, which allows calls with multiple * and ** unpacking: ```python bar(*args1, 99, *args2, 101, **kwargs1, kz=200, **kwargs2) ``` and ```c++ bar(*args1, 99, *args2, 101, **kwargs1, "kz"_a=200, **kwargs2) ```
2016-08-29 01:05:42 +00:00
#if defined(NDEBUG)
argument_cast_error();
#else
Make keyword argument hold a py::object instead of T* With this change arg_t is no longer a template, but it must remain so for backward compatibility. Thus, a non-template arg_v is introduced, while a dummy template alias arg_t is there to keep old code from breaking. This can be remove in the next major release. The implementation of arg_v also needed to be placed a little earlier in the headers because it's not a template any more and unpacking_collector needs more than a forward declaration.
2016-09-05 22:49:21 +00:00
argument_cast_error(a.name, a.type);
Support keyword arguments and generalized unpacking in C++ A Python function can be called with the syntax: ```python foo(a1, a2, *args, ka=1, kb=2, **kwargs) ``` This commit adds support for the equivalent syntax in C++: ```c++ foo(a1, a2, *args, "ka"_a=1, "kb"_a=2, **kwargs) ``` In addition, generalized unpacking is implemented, as per PEP 448, which allows calls with multiple * and ** unpacking: ```python bar(*args1, 99, *args2, 101, **kwargs1, kz=200, **kwargs2) ``` and ```c++ bar(*args1, 99, *args2, 101, **kwargs1, "kz"_a=200, **kwargs2) ```
2016-08-29 01:05:42 +00:00
#endif
}
Make keyword argument hold a py::object instead of T* With this change arg_t is no longer a template, but it must remain so for backward compatibility. Thus, a non-template arg_v is introduced, while a dummy template alias arg_t is there to keep old code from breaking. This can be remove in the next major release. The implementation of arg_v also needed to be placed a little earlier in the headers because it's not a template any more and unpacking_collector needs more than a forward declaration.
2016-09-05 22:49:21 +00:00
m_kwargs[a.name] = a.value;
Support keyword arguments and generalized unpacking in C++ A Python function can be called with the syntax: ```python foo(a1, a2, *args, ka=1, kb=2, **kwargs) ``` This commit adds support for the equivalent syntax in C++: ```c++ foo(a1, a2, *args, "ka"_a=1, "kb"_a=2, **kwargs) ``` In addition, generalized unpacking is implemented, as per PEP 448, which allows calls with multiple * and ** unpacking: ```python bar(*args1, 99, *args2, 101, **kwargs1, kz=200, **kwargs2) ``` and ```c++ bar(*args1, 99, *args2, 101, **kwargs1, "kz"_a=200, **kwargs2) ```
2016-08-29 01:05:42 +00:00
}
void process(list &/*args_list*/, detail::kwargs_proxy kp) {
unpacking_collector: allow nullptr-valued kwargs argument This fixes an issue that can arise when forwarding (*args, **kwargs) captured from a pybind11-bound function call to another Python function. When the initial function call includes no keyword arguments, the py::kwargs field is set to nullptr and causes a crash later on.
2016-10-08 13:30:00 +00:00
if (!kp)
return;
Add py::reinterpret_borrow<T>()/steal<T>() for low-level unchecked casts The pytype converting constructors are convenient and safe for user code, but for library internals the additional type checks and possible conversions are sometimes not desired. `reinterpret_borrow<T>()` and `reinterpret_steal<T>()` serve as the low-level unsafe counterparts of `cast<T>()`. This deprecates the `object(handle, bool)` constructor. Renamed `borrowed` parameter to `is_borrowed` to avoid shadowing warnings on MSVC.
2016-10-28 01:08:15 +00:00
for (const auto &k : reinterpret_borrow<dict>(kp)) {
Make attr and item accessors throw on error instead of returning nullptr This also adds the `hasattr` and `getattr` functions which are needed with the new attribute behavior. The new functions behave exactly like their Python counterparts. Similarly `object` gets a `contains` method which calls `__contains__`, i.e. it's the same as the `in` keyword in Python.
2016-09-20 23:06:32 +00:00
if (m_kwargs.contains(k.first)) {
Support keyword arguments and generalized unpacking in C++ A Python function can be called with the syntax: ```python foo(a1, a2, *args, ka=1, kb=2, **kwargs) ``` This commit adds support for the equivalent syntax in C++: ```c++ foo(a1, a2, *args, "ka"_a=1, "kb"_a=2, **kwargs) ``` In addition, generalized unpacking is implemented, as per PEP 448, which allows calls with multiple * and ** unpacking: ```python bar(*args1, 99, *args2, 101, **kwargs1, kz=200, **kwargs2) ``` and ```c++ bar(*args1, 99, *args2, 101, **kwargs1, "kz"_a=200, **kwargs2) ```
2016-08-29 01:05:42 +00:00
#if defined(NDEBUG)
multiple_values_error();
#else
Add default and converting constructors for all concrete Python types * Deprecate the `py::object::str()` member function since `py::str(obj)` is now equivalent and preferred * Make `py::repr()` a free function * Make sure obj.cast<T>() works as expected when T is a Python type `obj.cast<T>()` should be the same as `T(obj)`, i.e. it should convert the given object to a different Python type. However, `obj.cast<T>()` usually calls `type_caster::load()` which only checks the type without doing any actual conversion. That causes a very unexpected `cast_error`. This commit makes it so that `obj.cast<T>()` and `T(obj)` are the same when T is a Python type. * Simplify pytypes converting constructor implementation It's not necessary to maintain a full set of converting constructors and assignment operators + const& and &&. A single converting const& constructor will work and there is no impact on binary size. On the other hand, the conversion functions can be significantly simplified.
2016-10-25 20:12:39 +00:00
multiple_values_error(str(k.first));
Support keyword arguments and generalized unpacking in C++ A Python function can be called with the syntax: ```python foo(a1, a2, *args, ka=1, kb=2, **kwargs) ``` This commit adds support for the equivalent syntax in C++: ```c++ foo(a1, a2, *args, "ka"_a=1, "kb"_a=2, **kwargs) ``` In addition, generalized unpacking is implemented, as per PEP 448, which allows calls with multiple * and ** unpacking: ```python bar(*args1, 99, *args2, 101, **kwargs1, kz=200, **kwargs2) ``` and ```c++ bar(*args1, 99, *args2, 101, **kwargs1, "kz"_a=200, **kwargs2) ```
2016-08-29 01:05:42 +00:00
#endif
}
m_kwargs[k.first] = k.second;
}
}
Add support for non-converting arguments This adds support for controlling the `convert` flag of arguments through the py::arg annotation. This then allows arguments to be flagged as non-converting, which the type_caster is able to use to request different behaviour. Currently, AFAICS `convert` is only used for type converters of regular pybind11-registered types; all of the other core type_casters ignore it. We can, however, repurpose it to control internal conversion of converters like Eigen and `array`: most usefully to give callers a way to disable the conversion that would otherwise occur when a `Eigen::Ref<const Eigen::Matrix>` argument is passed a numpy array that requires conversion (either because it has an incompatible stride or the wrong dtype). Specifying a noconvert looks like one of these: m.def("f1", &f, "a"_a.noconvert() = "default"); // Named, default, noconvert m.def("f2", &f, "a"_a.noconvert()); // Named, no default, no converting m.def("f3", &f, py::arg().noconvert()); // Unnamed, no default, no converting (The last part--being able to declare a py::arg without a name--is new: previous py::arg() only accepted named keyword arguments). Such an non-convert argument is then passed `convert = false` by the type caster when loading the argument. Whether this has an effect is up to the type caster itself, but as mentioned above, this would be extremely helpful for the Eigen support to give a nicer way to specify a "no-copy" mode than the custom wrapper in the current PR, and moreover isn't an Eigen-specific hack.
2017-01-23 08:50:00 +00:00
[[noreturn]] static void nameless_argument_error() {
throw type_error("Got kwargs without a name; only named arguments "
"may be passed via py::arg() to a python function call. "
"(compile in debug mode for details)");
}
[[noreturn]] static void nameless_argument_error(std::string type) {
throw type_error("Got kwargs without a name of type '" + type + "'; only named "
"arguments may be passed via py::arg() to a python function call. ");
}
Support keyword arguments and generalized unpacking in C++ A Python function can be called with the syntax: ```python foo(a1, a2, *args, ka=1, kb=2, **kwargs) ``` This commit adds support for the equivalent syntax in C++: ```c++ foo(a1, a2, *args, "ka"_a=1, "kb"_a=2, **kwargs) ``` In addition, generalized unpacking is implemented, as per PEP 448, which allows calls with multiple * and ** unpacking: ```python bar(*args1, 99, *args2, 101, **kwargs1, kz=200, **kwargs2) ``` and ```c++ bar(*args1, 99, *args2, 101, **kwargs1, "kz"_a=200, **kwargs2) ```
2016-08-29 01:05:42 +00:00
[[noreturn]] static void multiple_values_error() {
throw type_error("Got multiple values for keyword argument "
"(compile in debug mode for details)");
}
[[noreturn]] static void multiple_values_error(std::string name) {
throw type_error("Got multiple values for keyword argument '" + name + "'");
}
[[noreturn]] static void argument_cast_error() {
throw cast_error("Unable to convert call argument to Python object "
"(compile in debug mode for details)");
}
[[noreturn]] static void argument_cast_error(std::string name, std::string type) {
throw cast_error("Unable to convert call argument '" + name
+ "' of type '" + type + "' to Python object");
}
private:
tuple m_args;
dict m_kwargs;
};
/// Collect only positional arguments for a Python function call
template <return_value_policy policy, typename... Args,
Change all_of_t/any_of_t to all_of/any_of, add none_of This replaces the current `all_of_t<Pred, Ts...>` with `all_of<Ts...>`, with previous use of `all_of_t<Pred, Ts...>` becoming `all_of<Pred<Ts>...>` (and similarly for `any_of_t`). It also adds a `none_of<Ts...>`, a shortcut for `negation<any_of<Ts...>>`. This allows `all_of` and `any_of` to be used a bit more flexible, e.g. in cases where several predicates need to be tested for the same type instead of the same predicate for multiple types. This commit replaces the implementation with a more efficient version for non-MSVC. For MSVC, this changes the workaround to use the built-in, recursive std::conjunction/std::disjunction instead. This also removes the `count_t` since `any_of_t` and `all_of_t` were the only things using it. This commit also rearranges some of the future std imports to use actual `std` implementations for C++14/17 features when under the appropriate compiler mode, as we were already doing for a few things (like index_sequence). Most of these aren't saving much (the implementation for enable_if_t, for example, is trivial), but I think it makes the intention of the code instantly clear. It also enables MSVC's native std::index_sequence support.
2016-12-12 23:11:49 +00:00
typename = enable_if_t<all_of<is_positional<Args>...>::value>>
Support keyword arguments and generalized unpacking in C++ A Python function can be called with the syntax: ```python foo(a1, a2, *args, ka=1, kb=2, **kwargs) ``` This commit adds support for the equivalent syntax in C++: ```c++ foo(a1, a2, *args, "ka"_a=1, "kb"_a=2, **kwargs) ``` In addition, generalized unpacking is implemented, as per PEP 448, which allows calls with multiple * and ** unpacking: ```python bar(*args1, 99, *args2, 101, **kwargs1, kz=200, **kwargs2) ``` and ```c++ bar(*args1, 99, *args2, 101, **kwargs1, "kz"_a=200, **kwargs2) ```
2016-08-29 01:05:42 +00:00
simple_collector<policy> collect_arguments(Args &&...args) {
Disable most implicit conversion constructors We have various classes that have non-explicit constructors that accept a single argument, which is implicitly making them implicitly convertible from the argument. In a few cases, this is desirable (e.g. implicit conversion of std::string to py::str, or conversion of double to py::float_); in many others, however, it is unintended (e.g. implicit conversion of size_t to some pre-declared py::array_t<T> type). This disables most of the unwanted implicit conversions by marking them `explicit`, and comments the ones that are deliberately left implicit.
2016-10-16 20:27:42 +00:00
return simple_collector<policy>(std::forward<Args>(args)...);
Support keyword arguments and generalized unpacking in C++ A Python function can be called with the syntax: ```python foo(a1, a2, *args, ka=1, kb=2, **kwargs) ``` This commit adds support for the equivalent syntax in C++: ```c++ foo(a1, a2, *args, "ka"_a=1, "kb"_a=2, **kwargs) ``` In addition, generalized unpacking is implemented, as per PEP 448, which allows calls with multiple * and ** unpacking: ```python bar(*args1, 99, *args2, 101, **kwargs1, kz=200, **kwargs2) ``` and ```c++ bar(*args1, 99, *args2, 101, **kwargs1, "kz"_a=200, **kwargs2) ```
2016-08-29 01:05:42 +00:00
}
/// Collect all arguments, including keywords and unpacking (only instantiated when needed)
template <return_value_policy policy, typename... Args,
Change all_of_t/any_of_t to all_of/any_of, add none_of This replaces the current `all_of_t<Pred, Ts...>` with `all_of<Ts...>`, with previous use of `all_of_t<Pred, Ts...>` becoming `all_of<Pred<Ts>...>` (and similarly for `any_of_t`). It also adds a `none_of<Ts...>`, a shortcut for `negation<any_of<Ts...>>`. This allows `all_of` and `any_of` to be used a bit more flexible, e.g. in cases where several predicates need to be tested for the same type instead of the same predicate for multiple types. This commit replaces the implementation with a more efficient version for non-MSVC. For MSVC, this changes the workaround to use the built-in, recursive std::conjunction/std::disjunction instead. This also removes the `count_t` since `any_of_t` and `all_of_t` were the only things using it. This commit also rearranges some of the future std imports to use actual `std` implementations for C++14/17 features when under the appropriate compiler mode, as we were already doing for a few things (like index_sequence). Most of these aren't saving much (the implementation for enable_if_t, for example, is trivial), but I think it makes the intention of the code instantly clear. It also enables MSVC's native std::index_sequence support.
2016-12-12 23:11:49 +00:00
typename = enable_if_t<!all_of<is_positional<Args>...>::value>>
Support keyword arguments and generalized unpacking in C++ A Python function can be called with the syntax: ```python foo(a1, a2, *args, ka=1, kb=2, **kwargs) ``` This commit adds support for the equivalent syntax in C++: ```c++ foo(a1, a2, *args, "ka"_a=1, "kb"_a=2, **kwargs) ``` In addition, generalized unpacking is implemented, as per PEP 448, which allows calls with multiple * and ** unpacking: ```python bar(*args1, 99, *args2, 101, **kwargs1, kz=200, **kwargs2) ``` and ```c++ bar(*args1, 99, *args2, 101, **kwargs1, "kz"_a=200, **kwargs2) ```
2016-08-29 01:05:42 +00:00
unpacking_collector<policy> collect_arguments(Args &&...args) {
// Following argument order rules for generalized unpacking according to PEP 448
static_assert(
constexpr_last<is_positional, Args...>() < constexpr_first<is_keyword_or_ds, Args...>()
&& constexpr_last<is_s_unpacking, Args...>() < constexpr_first<is_ds_unpacking, Args...>(),
"Invalid function call: positional args must precede keywords and ** unpacking; "
"* unpacking must precede ** unpacking"
);
Disable most implicit conversion constructors We have various classes that have non-explicit constructors that accept a single argument, which is implicitly making them implicitly convertible from the argument. In a few cases, this is desirable (e.g. implicit conversion of std::string to py::str, or conversion of double to py::float_); in many others, however, it is unintended (e.g. implicit conversion of size_t to some pre-declared py::array_t<T> type). This disables most of the unwanted implicit conversions by marking them `explicit`, and comments the ones that are deliberately left implicit.
2016-10-16 20:27:42 +00:00
return unpacking_collector<policy>(std::forward<Args>(args)...);
Support keyword arguments and generalized unpacking in C++ A Python function can be called with the syntax: ```python foo(a1, a2, *args, ka=1, kb=2, **kwargs) ``` This commit adds support for the equivalent syntax in C++: ```c++ foo(a1, a2, *args, "ka"_a=1, "kb"_a=2, **kwargs) ``` In addition, generalized unpacking is implemented, as per PEP 448, which allows calls with multiple * and ** unpacking: ```python bar(*args1, 99, *args2, 101, **kwargs1, kz=200, **kwargs2) ``` and ```c++ bar(*args1, 99, *args2, 101, **kwargs1, "kz"_a=200, **kwargs2) ```
2016-08-29 01:05:42 +00:00
}
Move common object functions into object_api mixin
2016-09-08 14:36:01 +00:00
template <typename Derived>
Support keyword arguments and generalized unpacking in C++ A Python function can be called with the syntax: ```python foo(a1, a2, *args, ka=1, kb=2, **kwargs) ``` This commit adds support for the equivalent syntax in C++: ```c++ foo(a1, a2, *args, "ka"_a=1, "kb"_a=2, **kwargs) ``` In addition, generalized unpacking is implemented, as per PEP 448, which allows calls with multiple * and ** unpacking: ```python bar(*args1, 99, *args2, 101, **kwargs1, kz=200, **kwargs2) ``` and ```c++ bar(*args1, 99, *args2, 101, **kwargs1, "kz"_a=200, **kwargs2) ```
2016-08-29 01:05:42 +00:00
template <return_value_policy policy, typename... Args>
Move common object functions into object_api mixin
2016-09-08 14:36:01 +00:00
object object_api<Derived>::operator()(Args &&...args) const {
return detail::collect_arguments<policy>(std::forward<Args>(args)...).call(derived().ptr());
Initial commit
2015-07-05 18:05:44 +00:00
}
Move common object functions into object_api mixin
2016-09-08 14:36:01 +00:00
template <typename Derived>
template <return_value_policy policy, typename... Args>
object object_api<Derived>::call(Args &&...args) const {
allow passing a 'return value policy' to handle::operator()
2016-06-22 12:29:13 +00:00
return operator()<policy>(std::forward<Args>(args)...);
enable *args and **kwargs notation (closes #190)
2016-05-08 12:34:09 +00:00
}
Move common object functions into object_api mixin
2016-09-08 14:36:01 +00:00
NAMESPACE_END(detail)
Improve macro type handling for types with commas - PYBIND11_MAKE_OPAQUE now takes ... rather than a single argument and expands it with __VA_ARGS__; this lets templated, comma-containing types get through correctly. - Adds a new macro PYBIND11_TYPE() that lets you pass the type into a macro as a single argument, such as: PYBIND11_OVERLOAD(PYBIND11_TYPE(R<1,2>), PYBIND11_TYPE(C<3,4>), func) Unfortunately this only works for one macro call: to forward the argument on to the next macro call (without the processor breaking it up again) requires also adding the PYBIND11_TYPE(...) to type macro arguments in the PYBIND11_OVERLOAD_... macro chain. - updated the documentation with these two changes, and use them at a couple places in the test suite to test that they work.
2018-02-28 02:33:41 +00:00
#define PYBIND11_MAKE_OPAQUE(...) \
opaque type redesign
2016-04-28 14:25:24 +00:00
namespace pybind11 { namespace detail { \
Improve macro type handling for types with commas - PYBIND11_MAKE_OPAQUE now takes ... rather than a single argument and expands it with __VA_ARGS__; this lets templated, comma-containing types get through correctly. - Adds a new macro PYBIND11_TYPE() that lets you pass the type into a macro as a single argument, such as: PYBIND11_OVERLOAD(PYBIND11_TYPE(R<1,2>), PYBIND11_TYPE(C<3,4>), func) Unfortunately this only works for one macro call: to forward the argument on to the next macro call (without the processor breaking it up again) requires also adding the PYBIND11_TYPE(...) to type macro arguments in the PYBIND11_OVERLOAD_... macro chain. - updated the documentation with these two changes, and use them at a couple places in the test suite to test that they work.
2018-02-28 02:33:41 +00:00
template<> class type_caster<__VA_ARGS__> : public type_caster_base<__VA_ARGS__> { }; \
opaque type redesign
2016-04-28 14:25:24 +00:00
}}
Improve macro type handling for types with commas - PYBIND11_MAKE_OPAQUE now takes ... rather than a single argument and expands it with __VA_ARGS__; this lets templated, comma-containing types get through correctly. - Adds a new macro PYBIND11_TYPE() that lets you pass the type into a macro as a single argument, such as: PYBIND11_OVERLOAD(PYBIND11_TYPE(R<1,2>), PYBIND11_TYPE(C<3,4>), func) Unfortunately this only works for one macro call: to forward the argument on to the next macro call (without the processor breaking it up again) requires also adding the PYBIND11_TYPE(...) to type macro arguments in the PYBIND11_OVERLOAD_... macro chain. - updated the documentation with these two changes, and use them at a couple places in the test suite to test that they work.
2018-02-28 02:33:41 +00:00
/// Lets you pass a type containing a `,` through a macro parameter without needing a separate
/// typedef, e.g.: `PYBIND11_OVERLOAD(PYBIND11_TYPE(ReturnType<A, B>), PYBIND11_TYPE(Parent<C, D>), f, arg)`
#define PYBIND11_TYPE(...) __VA_ARGS__
Force hidden visibility on pybind code This adds a PYBIND11_NAMESPACE macro that expands to the `pybind11` namespace with hidden visibility under gcc-type compilers, and otherwise to the plain `pybind11`. This then forces hidden visibility on everything in pybind, solving the visibility issues discussed at end end of #949.
2017-08-10 16:03:29 +00:00
NAMESPACE_END(PYBIND11_NAMESPACE)
Reference in New Issue Copy Permalink