GitLab

Bugfix: bad delete if no copy ctor

* Remove obsolete example reference
* Make example fully-working (except for #includes)

Fixes #456.

Fix def_property and related functions

Making `cppfunction` explicit broke `def_property` and friends.
The added tests would not compile without an implicit `cppfunction`.

Without the previous commit, this test generates a core dump.

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.

Support std::shared_ptr holder type out of the box

Reorganize documentation

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.

Auto-implement format/numpy descriptors for enum types

Make operator bool() explicit

This prevents unwanted conversions to bool or int such as:
```
py::object my_object;

std::cout << my_object << std::endl; // compiles and prints 0 or 1
int n = my_object; // compiles and is nonsense
```

With `explicit operator bool()` the above cases become compiler errors.

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.

Accept any sequence type as std::vector (or std::list)

Accept any sequence type as std::vector

Fix dynamic attribute inheritance in C++

`PyType_Ready` would usually perform the inheritance for us, but it
can't adjust `tp_basicsize` appropriately.

Add dynamic attribute support

This convenience function ensures that a py::object is either a
py::array, or the implementation will try to convert it into one. Layout
requirements (such as c_style or f_style) can be also be provided.

Permit creation of NumPy arrays with a "base" object that owns the data

This patch adds an extra base handle parameter to most ``py::array`` and
``py::array_t<>`` constructors. If specified along with a pointer to
data, the base object will be registered within NumPy, which increases
the base's reference count. This feature is useful to create shallow
copies of C++ or Python arrays while ensuring that the owners of the
underlying can't be garbage collected while referenced by NumPy.

The commit also adds a simple test function involving a ``wrap()``
function that creates shallow copies of various N-D arrays.

- This actually works with no changes, I just wasn't 100% convinced and
  decided to write a test to see if it's true.

extra python version sanity check at import time