smart_ptrs.rst revision 12037:d28054ac6ec9
1Smart pointers 2############## 3 4std::unique_ptr 5=============== 6 7Given a class ``Example`` with Python bindings, it's possible to return 8instances wrapped in C++11 unique pointers, like so 9 10.. code-block:: cpp 11 12 std::unique_ptr<Example> create_example() { return std::unique_ptr<Example>(new Example()); } 13 14.. code-block:: cpp 15 16 m.def("create_example", &create_example); 17 18In other words, there is nothing special that needs to be done. While returning 19unique pointers in this way is allowed, it is *illegal* to use them as function 20arguments. For instance, the following function signature cannot be processed 21by pybind11. 22 23.. code-block:: cpp 24 25 void do_something_with_example(std::unique_ptr<Example> ex) { ... } 26 27The above signature would imply that Python needs to give up ownership of an 28object that is passed to this function, which is generally not possible (for 29instance, the object might be referenced elsewhere). 30 31std::shared_ptr 32=============== 33 34The binding generator for classes, :class:`class_`, can be passed a template 35type that denotes a special *holder* type that is used to manage references to 36the object. If no such holder type template argument is given, the default for 37a type named ``Type`` is ``std::unique_ptr<Type>``, which means that the object 38is deallocated when Python's reference count goes to zero. 39 40It is possible to switch to other types of reference counting wrappers or smart 41pointers, which is useful in codebases that rely on them. For instance, the 42following snippet causes ``std::shared_ptr`` to be used instead. 43 44.. code-block:: cpp 45 46 py::class_<Example, std::shared_ptr<Example> /* <- holder type */> obj(m, "Example"); 47 48Note that any particular class can only be associated with a single holder type. 49 50One potential stumbling block when using holder types is that they need to be 51applied consistently. Can you guess what's broken about the following binding 52code? 53 54.. code-block:: cpp 55 56 class Child { }; 57 58 class Parent { 59 public: 60 Parent() : child(std::make_shared<Child>()) { } 61 Child *get_child() { return child.get(); } /* Hint: ** DON'T DO THIS ** */ 62 private: 63 std::shared_ptr<Child> child; 64 }; 65 66 PYBIND11_PLUGIN(example) { 67 py::module m("example"); 68 69 py::class_<Child, std::shared_ptr<Child>>(m, "Child"); 70 71 py::class_<Parent, std::shared_ptr<Parent>>(m, "Parent") 72 .def(py::init<>()) 73 .def("get_child", &Parent::get_child); 74 75 return m.ptr(); 76 } 77 78The following Python code will cause undefined behavior (and likely a 79segmentation fault). 80 81.. code-block:: python 82 83 from example import Parent 84 print(Parent().get_child()) 85 86The problem is that ``Parent::get_child()`` returns a pointer to an instance of 87``Child``, but the fact that this instance is already managed by 88``std::shared_ptr<...>`` is lost when passing raw pointers. In this case, 89pybind11 will create a second independent ``std::shared_ptr<...>`` that also 90claims ownership of the pointer. In the end, the object will be freed **twice** 91since these shared pointers have no way of knowing about each other. 92 93There are two ways to resolve this issue: 94 951. For types that are managed by a smart pointer class, never use raw pointers 96 in function arguments or return values. In other words: always consistently 97 wrap pointers into their designated holder types (such as 98 ``std::shared_ptr<...>``). In this case, the signature of ``get_child()`` 99 should be modified as follows: 100 101.. code-block:: cpp 102 103 std::shared_ptr<Child> get_child() { return child; } 104 1052. Adjust the definition of ``Child`` by specifying 106 ``std::enable_shared_from_this<T>`` (see cppreference_ for details) as a 107 base class. This adds a small bit of information to ``Child`` that allows 108 pybind11 to realize that there is already an existing 109 ``std::shared_ptr<...>`` and communicate with it. In this case, the 110 declaration of ``Child`` should look as follows: 111 112.. _cppreference: http://en.cppreference.com/w/cpp/memory/enable_shared_from_this 113 114.. code-block:: cpp 115 116 class Child : public std::enable_shared_from_this<Child> { }; 117 118.. _smart_pointers: 119 120Custom smart pointers 121===================== 122 123pybind11 supports ``std::unique_ptr`` and ``std::shared_ptr`` right out of the 124box. For any other custom smart pointer, transparent conversions can be enabled 125using a macro invocation similar to the following. It must be declared at the 126top namespace level before any binding code: 127 128.. code-block:: cpp 129 130 PYBIND11_DECLARE_HOLDER_TYPE(T, SmartPtr<T>); 131 132The first argument of :func:`PYBIND11_DECLARE_HOLDER_TYPE` should be a 133placeholder name that is used as a template parameter of the second argument. 134Thus, feel free to use any identifier, but use it consistently on both sides; 135also, don't use the name of a type that already exists in your codebase. 136 137The macro also accepts a third optional boolean parameter that is set to false 138by default. Specify 139 140.. code-block:: cpp 141 142 PYBIND11_DECLARE_HOLDER_TYPE(T, SmartPtr<T>, true); 143 144if ``SmartPtr<T>`` can always be initialized from a ``T*`` pointer without the 145risk of inconsistencies (such as multiple independent ``SmartPtr`` instances 146believing that they are the sole owner of the ``T*`` pointer). A common 147situation where ``true`` should be passed is when the ``T`` instances use 148*intrusive* reference counting. 149 150Please take a look at the :ref:`macro_notes` before using this feature. 151 152By default, pybind11 assumes that your custom smart pointer has a standard 153interface, i.e. provides a ``.get()`` member function to access the underlying 154raw pointer. If this is not the case, pybind11's ``holder_helper`` must be 155specialized: 156 157.. code-block:: cpp 158 159 // Always needed for custom holder types 160 PYBIND11_DECLARE_HOLDER_TYPE(T, SmartPtr<T>); 161 162 // Only needed if the type's `.get()` goes by another name 163 namespace pybind11 { namespace detail { 164 template <typename T> 165 struct holder_helper<SmartPtr<T>> { // <-- specialization 166 static const T *get(const SmartPtr<T> &p) { return p.getPointer(); } 167 }; 168 }} 169 170The above specialization informs pybind11 that the custom ``SmartPtr`` class 171provides ``.get()`` functionality via ``.getPointer()``. 172 173.. seealso:: 174 175 The file :file:`tests/test_smart_ptr.cpp` contains a complete example 176 that demonstrates how to work with custom reference-counting holder types 177 in more detail. 178