Commit Graph

2987 Commits

Author SHA1 Message Date
Jason Rhinelander
9f6a636e54 detail/init.h: fix the "see above" comments
The "see above" comment being referenced in the code comments isn't
"above" anymore; copy the later factory init comment into the first
constructor block to fix it.
2017-08-21 16:50:46 -04:00
Dean Moldovan
1fb9df601c Add upgrade guide to the documentation
[skip ci]
2017-08-21 01:12:45 +02:00
Dean Moldovan
db46a89d96 Update changelog for v2.2.0
[skip ci]
2017-08-21 00:59:48 +02:00
Patrik Huber
d265933d85 Fix typos in Eigen documentation
Fixes one small variable name typo, and two instances where `py::arg().nocopy()` is used, where I think it should be `py::arg().noconvert()` instead. Probably `nocopy()` was the old/original name for it and then it was changed.
2017-08-19 15:31:32 -04:00
Jason Rhinelander
5e14aa6aa7 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-19 15:30:39 -04:00
Jason Rhinelander
39498b2bd3 Remove PYBIND11_UNSHARED_STATIC_LOCALS macro
The macro isn't doing anything useful now that hidden visibility is
applied to all pybind11 code.
2017-08-17 11:34:43 -04:00
Jason Rhinelander
c4e180081d Reimplement py::init<...> to use common factory code
This reimplements the py::init<...> implementations using the various
functions added to support `py::init(...)`, and moves the implementing
structs into `detail/init.h` from `pybind11.h`.  It doesn't simply use a
factory directly, as this is a very common case and implementation
without an extra lambda call is a small but useful optimization.

This, combined with the previous lazy initialization, also avoids
needing placement new for `py::init<...>()` construction: such
construction now occurs via an ordinary `new Type(...)`.

A consequence of this is that it also fixes a potential bug when using
multiple inheritance from Python: it was very easy to write classes
that double-initialize an existing instance which had the potential to
leak for non-pod classes.  With the new implementation, an attempt to
call `__init__` on an already-initialized object is now ignored.  (This
was already done in the previous commit for factory constructors).

This change exposed a few warnings (fixed here) from deleting a pointer
to a base class with virtual functions but without a virtual destructor.
These look like legitimate warnings that we shouldn't suppress; this
adds virtual destructors to the appropriate classes.
2017-08-17 09:33:27 -04:00
Jason Rhinelander
464d98962d 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-08-17 09:33:27 -04:00
Jason Rhinelander
42e5ddc541 Add a polymorphic static assert when using an alias
An alias can be used for two main purposes: to override virtual methods,
and to add some extra data to a class needed for the pybind-wrapper.
Both of these absolutely require that the wrapped class be polymorphic
so that virtual dispatch and destruction, respectively, works.
2017-08-17 09:33:27 -04:00
Jason Rhinelander
b4bf5ed575 Added metatypes for dealing with functions/lambdas
`function_signature_t` extracts the function type from a function,
function pointer, or lambda.

`is_lambda` (which is really
`is_not_a_function_or_pointer_or_member_pointer`, but that name is a
bit too long) checks whether the type is (in the approprate context) a
lambda.

`is_function_pointer` checks whether the type is a pointer to a
function.
2017-08-17 09:33:27 -04:00
Jason Rhinelander
fd81a03ec9 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-17 09:33:27 -04:00
Dean Moldovan
8665ee8100 Fix documentation build
* Doxygen needs `RECURSIVE = YES` in order to parse the `detail` subdir.

* The `-W` warnings-as-errors option for sphinx doesn't work with the
  makefile build. Switched to calling sphinx directly.

* Fix "citation [cppimport] is not referenced" warning.
2017-08-17 15:10:51 +02:00
Jason Rhinelander
0d703f6e7c Don't force hidden visibility on the embed target, just the module target
Embedding may well be used in places where hidden visibility isn't
desired.  It should be relatively safe to allow it there; any potential
conflict would come in if modules are loaded into that embedded
interpreter, but as long as the modules are compiled with hidden
visibility they shouldn't conflict.

There could still be warnings if the embedded code attempts to export
classes with internal (hidden) pybind members, but that seems a
legitimate warning (and already has a FAQ entry).
2017-08-17 01:57:31 -04:00
Dean Moldovan
f580649871 Move internal headers into detail subdirectory 2017-08-17 04:06:35 +02:00
Dean Moldovan
76e06c89e4 Avoid duplicate C++ standard flags if CMAKE_CXX_STANDARD is set
CMAKE_CXX_STANDARD is only available on CMake >= 3.1. If the flag is
set, we avoid initializing PYBIND11_CPP_STANDARD.
2017-08-17 03:04:44 +02:00
Jason Rhinelander
97aa54fefa Compile with hidden visibility always; set via cmake property rather than compiler flag
This updates the compilation to always apply hidden visibility to
resolve the issues with default visibility causing problems under debug
compilations.  Moreover using the cmake property makes it easier for a
caller to override if absolutely needed for some reason.

For `pybind11_add_module` we use cmake to set the property; for the
targets, we append to compilation option to non-MSVC compilers.
2017-08-14 11:44:17 -04:00
Jason Rhinelander
a859dd67a2 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-14 11:40:38 -04:00
Dean Moldovan
8d3cedbe2b Add test for mixing STL casters and local binders across modules
One module uses a generic vector caster from `<pybind11/stl.h>` while
the other exports `std::vector<int>` with a local `py:bind_vector`.
2017-08-14 01:11:52 +02:00
Jason Rhinelander
eb0f1cc7bf Only allow unchecked()/mutable_unchecked() on an lvalue
This should mitigate accidental invocation on a temporary array.

Fixes #961.
2017-08-12 23:10:14 -04:00
Dean Moldovan
7918bcc95b Add support for boost::variant in C++11 mode
In C++11 mode, `boost::apply_visitor` requires an explicit `result_type`.
This also adds optional tests for `boost::variant` in C++11/14, if boost
is available. In C++17 mode, `std::variant` is tested instead.
2017-08-12 21:27:44 +02:00
EricCousineau-TRI
e06077bf47 Document the requirement to explicitly initialize C++ bases (#986)
* Ensure :ref: for virtual_and_inheritance is parsed.

* Add quick blurb about __init__ with inherited types.

[skip ci]
2017-08-08 00:37:42 +02:00
Dean Moldovan
3dde6ddc53 Add test for custom CMake export group 2017-08-07 23:08:20 +02:00
Ben Boeckel
017a747da6 CMake: support a custom export group (#970)
When Pybind11 is used via `add_subdirectory`, when targets are installed
from the parent project, CMake wants all of the dependencies built by
the project in the same export set. Projects may now set
`PYBIND11_EXPORT_NAME` to have Pybind11 put it targets into the
project's export set. If so, do not install Pybind11's export file.
2017-08-07 22:32:35 +02:00
Jason Rhinelander
ebd6ad588b Fix boost::variant example to not forward args
boost::apply_visitor accepts its arguments by non-const lvalue
reference, which fails to bind to an rvalue reference.  Change the
example to remove the argument forwarding.
2017-08-07 15:48:49 -04:00
Jason Rhinelander
391c75447d Update all remaining tests to new test styles
This udpates all the remaining tests to the new test suite code and
comment styles started in #898.  For the most part, the test coverage
here is unchanged, with a few minor exceptions as noted below.

- test_constants_and_functions: this adds more overload tests with
  overloads with different number of arguments for more comprehensive
  overload_cast testing.  The test style conversion broke the overload
  tests under MSVC 2015, prompting the additional tests while looking
  for a workaround.

- test_eigen: this dropped the unused functions `get_cm_corners` and
  `get_cm_corners_const`--these same tests were duplicates of the same
  things provided (and used) via ReturnTester methods.

- test_opaque_types: this test had a hidden dependence on ExampleMandA
  which is now fixed by using the global UserType which suffices for the
  relevant test.

- test_methods_and_attributes: this required some additions to UserType
  to make it usable as a replacement for the test's previous SimpleType:
  UserType gained a value mutator, and the `value` property is not
  mutable (it was previously readonly).  Some overload tests were also
  added to better test overload_cast (as described above).

- test_numpy_array: removed the untemplated mutate_data/mutate_data_t:
  the templated versions with an empty parameter pack expand to the same
  thing.

- test_stl: this was already mostly in the new style; this just tweaks
  things a bit, localizing a class, and adding some missing
  `// test_whatever` comments.

- test_virtual_functions: like `test_stl`, this was mostly in the new
  test style already, but needed some `// test_whatever` comments.
  This commit also moves the inherited virtual example code to the end
  of the file, after the main set of tests (since it is less important
  than the other tests, and rather length); it also got renamed to
  `test_inherited_virtuals` (from `test_inheriting_repeat`) because it
  tests both inherited virtual approaches, not just the repeat approach.
2017-08-05 18:46:22 -04:00
Jason Rhinelander
9866a0f994 test_class: use gc_collect instead of detail_reg_inst side-effect 2017-08-05 18:46:22 -04:00
Jason Rhinelander
b468a3cefc Ignore undefined name long errors on Python 3 2017-08-05 18:46:22 -04:00
Jason Rhinelander
3ed62218a8 overload_cast MSVC 2015 fix
The current `py::overload_cast` is hitting some ICEs under both MSVC
2015 and clang 3.8 on debian with the rewritten test suites; adding an
empty constexpr constructor to the `overload_cast_impl` class seems to
avoid the ICE.
2017-08-05 18:46:22 -04:00
Jason Rhinelander
4b159230d9 Made module_local types take precedence over global types
Attempting to mix py::module_local and non-module_local classes results
in some unexpected/undesirable behaviour:

- if a class is registered non-local by some other module, a later
  attempt to register it locally fails.  It doesn't need to: it is
  perfectly acceptable for the local registration to simply override
  the external global registration.
- going the other way (i.e. module `A` registers a type `T` locally,
  then `B` registers the same type `T` globally) causes a more serious
  issue: `A.T`'s constructors no longer work because the `self` argument
  gets converted to a `B.T`, which then fails to resolve.

Changing the cast precedence to prefer local over global fixes this and
makes it work more consistently, regardless of module load order.
2017-08-05 11:23:34 -04:00
Jason Rhinelander
2640c950ca Stash std::strings used for tp_name in internals
Types need `tp_name` set to a C-style string, but the current `strdup`
ends up with a leak (issue #977).  This avoids the strdup by storing
the `std::string` in internals so that during interpreter shutdown it
will be properly destroyed.
2017-08-05 11:22:15 -04:00
Jason Rhinelander
7437c69500 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-08-04 10:47:34 -04:00
Jason Rhinelander
d598172993 Fix builtin exception handlers to work across modules
The builtin exception handler currently doesn't work across modules
under clang/libc++ for builtin pybind exceptions like
`pybind11::error_already_set` or `pybind11::stop_iteration`: under
RTLD_LOCAL module loading clang considers each module's exception
classes distinct types.  This then means that the base exception
translator fails to catch the exceptions and the fall through to the
generic `std::exception` handler, which completely breaks things like
`stop_iteration`: only the `stop_iteration` of the first module loaded
actually works properly; later modules raise a RuntimeError with no
message when trying to invoke their iterators.

For example, two modules defined like this exhibit the behaviour under
clang++/libc++:

z1.cpp:
    #include <pybind11/pybind11.h>
    #include <pybind11/stl_bind.h>
    namespace py = pybind11;
    PYBIND11_MODULE(z1, m) {
        py::bind_vector<std::vector<long>>(m, "IntVector");
    }

z2.cpp:
    #include <pybind11/pybind11.h>
    #include <pybind11/stl_bind.h>
    namespace py = pybind11;
    PYBIND11_MODULE(z2, m) {
        py::bind_vector<std::vector<double>>(m, "FloatVector");
    }

Python:
    import z1, z2
    for i in z2.FloatVector():
        pass

results in:
    Traceback (most recent call last):
      File "zs.py", line 2, in <module>
        for i in z2.FloatVector():
    RuntimeError

This commit fixes the issue by adding a new exception translator each
time the internals pointer is initialized from python builtins: this
generally means the internals data was initialized by some other
module.  (The extra translator(s) are skipped under libstdc++).
2017-08-04 10:47:34 -04:00
Jason Rhinelander
0bd5979c77 Add cross-module test plugin
This adds the infrastructure for a separate test plugin for cross-module
tests.  (This commit contains no tests that actually use it, but the
following commits do; this is separated simply to provide a cleaner
commit history).
2017-08-04 10:47:34 -04:00
Jason Rhinelander
e98d31d697 Force hidden visibility on functions needing distinct static locals
This commit adds a PYBIND11_UNSHARED_STATIC_LOCALS macro that forces a
function to have hidden visibility under gcc and gcc-compatible
compilers.  gcc, in particular, needs this to to avoid sharing static
local variables across modules (which happens even under a RTLD_LOCAL
dlopen()!).  clang doesn't appear to have this issue, but the forced
visibility on internal pybind functions certainly won't hurt it and icc.

This updates the workaround from #862 to use this rather than the
version-specific template.
2017-08-04 10:47:34 -04:00
Jason Rhinelander
373da82486 Make PYBIND11_OBJECT_CVT only convert if the type check fails
Currently types that are capable of conversion always call their convert
function when invoked with a `py::object` which is actually the correct
type.  This means that code such as `py::cast<py::list>(obj)` and
`py::list l(obj.attr("list"))` make copies, which was an oversight
rather than an intentional feature.

While at first glance there might be something behind having
`py::list(obj)` make a copy (as it would in Python), this would be
inconsistent when you dig a little deeper because `py::list(l)`
*doesn't* make a copy for an existing `py::list l`, and having an
inconsistency within C++ would be worse than a C++ <-> Python
inconsistency.

It is possible to get around the copying using a
`reinterpret_borrow<list>(o)` (and this commit fixes one place, in
`embed.h`, that does so), but that seems a misuse of
`reinterpret_borrow`, which is really supposed to be just for dealing
with raw python-returned values, not `py::object`-derived wrappers which
are supposed to be higher level.

This changes the constructor of such converting types (i.e. anything
using PYBIND11_OBJECT_CVT -- `str`, `bool_`, `int_`, `float_`, `tuple`,
`dict`, `list`, `set`, `memoryview`) to reference rather than copy when
the check function passes.

It also adds an `object &&` constructor that is slightly more efficient
by avoiding an inc_ref when the check function passes.
2017-08-04 10:14:55 -04:00
Jason Rhinelander
cca20a7f8d 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 04:16:11 -04:00
Jason Rhinelander
85d63c3bcd Superclass typo fix
This didn't actually affect anything (because all the MI3 constructor
does is invoke MI2 with the same arguments anyway).
2017-07-29 03:54:25 -04:00
Jason Rhinelander
12be4cd418 Remove debugging
The "z" wasn't meant to be committed; it meant the C++17 optimization
here was never being used.
2017-07-29 03:53:45 -04:00
Jason Rhinelander
1682b67326 Simplify error_already_set
`error_already_set` is more complicated than it needs to be, partly
because it manages reference counts itself rather than using
`py::object`, and partly because it tries to do more exception clearing
than is needed.  This commit greatly simplifies it, and fixes #927.

Using `py::object` instead of `PyObject *` means we can rely on
implicit copy/move constructors.

The current logic did both a `PyErr_Clear` on deletion *and* a
`PyErr_Fetch` on creation.  I can't see how the `PyErr_Clear` on
deletion is ever useful: the `Fetch` on creation itself clears the
error, so the only way doing a `PyErr_Clear` on deletion could do
anything if is some *other* exception was raised while the
`error_already_set` object was alive--but in that case, clearing some
other exception seems wrong.  (Code that is worried about an exception
handler raising another exception would already catch a second
`error_already_set` from exception code).

The destructor itself called `clear()`, but `clear()` was a little bit
more paranoid that needed: it called `restore()` to restore the
currently captured error, but then immediately cleared it, using the
`PyErr_Restore` to release the references.  That's unnecessary: it's
valid for us to release the references manually.  This updates the code
to simply release the references on the three objects (preserving the
gil acquire).

`clear()`, however, also had the side effect of clearing the current
error, even if the current `error_already_set` didn't have a current
error (e.g. because of a previous `restore()` or `clear()` call).  I
don't really see how clearing the error here can ever actually be
useful: the only way the current error could be set is if you called
`restore()` (in which case the current stored error-related members have
already been released), or if some *other* code raised the error, in
which case `clear()` on *this* object is clearing an error for which it
shouldn't be responsible.

Neither of those seem like intentional or desirable features, and
manually requesting deletion of the stored references similarly seems
pointless, so I've just made `clear()` an empty method and marked it
deprecated.

This also fixes a minor potential issue with the destruction: it is
technically possible for `value` to be null (though this seems likely to
be rare in practice); this updates the check to look at `type` which
will always be non-null for a `Fetch`ed exception.

This also adds error_already_set round-trip throw tests to the test
suite.
2017-07-28 20:40:35 -04:00
Jason Rhinelander
abcf43d59c Convert test_exceptions to new testing style 2017-07-28 20:40:35 -04:00
Jason Rhinelander
353615f77e 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-28 20:39:33 -04:00
Jason Rhinelander
44a17e1f3d Convert test_multiple_inheritance to new style
Significant rearrangement, but no new tests added.
2017-07-28 20:39:33 -04:00
Jason Rhinelander
793726014d 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-28 20:37:45 -04:00
Ivan Smirnov
e07f75839d 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 11:02:43 -04:00
Jason Rhinelander
a03408c839 Add support custom sized operator deletes (#952)
If a class doesn't provide a `T::operator delete(void *)` but does have
a `T::operator delete(void *, size_t)` the latter is invoked by a
`delete someT`.  Pybind currently only look for and call the former;
this commit adds detection and calling of the latter when the former
doesn't exist.
2017-07-23 00:32:58 -04:00
Dustin Spicuzza
7c0e2c247b Document automatic upcasting of polymorphic types (#654)
Resolves #645.
2017-07-23 03:36:08 +02:00
Dean Moldovan
2e37fe09e1 Fix compatibility of FindPythonLibsNew.cmake and FindPythonLibs.cmake
Make sure `LibsNew` runs correctly if called after the old `Libs`.
2017-07-23 03:32:19 +02:00
bennorth
cb3d4065fe Fix refcounting for tp_base objects of new types (#950)
To fix a difficult-to-reproduce segfault on Python interpreter exit,
ensure that the tp_base field of a handful of new heap-types is
counted as a reference to that base type object.
2017-07-20 09:21:31 -04:00
Jason Rhinelander
60526d4636 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-16 11:04:43 -04:00
Jason Rhinelander
67a0cc4eed 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-16 11:04:43 -04:00