@@ -101,28 +101,48 @@ holder:
101
101
py::classh<Foo>(m, "Foo");
102
102
}
103
103
104
- There are three small differences compared to classic pybind11:
104
+ There are three small differences compared to Classic pybind11:
105
105
106
106
- ``#include <pybind11/smart_holder.h> `` is used instead of
107
107
``#include <pybind11/pybind11.h> ``.
108
108
109
+ - The ``PYBIND11_SMART_HOLDER_TYPE_CASTERS(Foo) `` macro is needed.
110
+
109
111
- ``py::classh `` is used instead of ``py::class_ ``.
110
112
111
- - The ``PYBIND11_SMART_HOLDER_TYPE_CASTERS(Foo) `` macro is needed.
113
+ To the 2nd bullet point, the ``PYBIND11_SMART_HOLDER_TYPE_CASTERS `` macro
114
+ needs to appear in all translation units with pybind11 bindings that involve
115
+ Python⇄C++ conversions for `Foo `. This is the biggest inconvenience of the
116
+ Conservative mode. Practically, at a larger scale it is best to work with a
117
+ pair of `.h ` and `.cpp ` files for the bindings code, with the macros in the
118
+ `.h ` files.
112
119
113
- To the 2nd bullet point, ``py::classh<Foo> `` is simply a shortcut for
120
+ To the 3rd bullet point, ``py::classh<Foo> `` is simply a shortcut for
114
121
``py::class_<Foo, py::smart_holder> ``. The shortcut makes it possible to
115
- switch to using ``py::smart_holder `` without messing up the indentation of
116
- existing code. However, when migrating code that uses ``py::class_<Foo,
117
- std::shared_ptr<Foo>> ``, currently ``std::shared_ptr<Foo> `` needs to be
118
- removed manually when switching to ``py::classh `` (#HelpAppreciated this
119
- could probably be avoided with a little bit of template metaprogramming).
122
+ switch to using ``py::smart_holder `` without disturbing the indentation of
123
+ existing code.
124
+
125
+ When migrating code that uses ``py::class_<Bar, std::shared_ptr<Bar>> ``
126
+ there are two alternatives. The first one is to use ``py::classh<Bar> ``:
127
+
128
+ .. code-block :: diff
129
+
130
+ - py::class_<Bar, std::shared_ptr<Bar>>(m, "Bar");
131
+ + py::classh<Bar>(m, "Bar");
132
+
133
+ This is clean and simple, but makes it difficult to fall back to Classic
134
+ mode if needed. The second alternative is to replace ``std::shared_ptr<Bar> ``
135
+ with ``PYBIND11_SH_AVL(Bar) ``:
120
136
121
- To the 3rd bullet point, the macro also needs to appear in other translation
122
- units with pybind11 bindings that involve Python⇄C++ conversions for
123
- `Foo `. This is the biggest inconvenience of the Conservative mode. Practically,
124
- at a larger scale it is best to work with a pair of `.h ` and `.cpp ` files
125
- for the bindings code, with the macros in the `.h ` files.
137
+ .. code-block :: diff
138
+
139
+ - py::class_<Bar, std::shared_ptr<Bar>>(m, "Bar");
140
+ + py::class_<Bar, PYBIND11_SH_AVL(Bar)>(m, "Bar");
141
+
142
+ The ``PYBIND11_SH_AVL `` macro substitutes ``py::smart_holder ``
143
+ in Conservative mode, or ``std::shared_ptr<Bar> `` in Classic mode.
144
+ See tests/test_classh_mock.cpp for an example. Note that the macro is also
145
+ designed to not disturb the indentation of existing code.
126
146
127
147
128
148
Progressive mode
@@ -132,47 +152,63 @@ To work in Progressive mode:
132
152
133
153
- Add ``-DPYBIND11_USE_SMART_HOLDER_AS_DEFAULT `` to the compilation commands.
134
154
135
- - Remove any ``std::shared_ptr<...> `` holders from existing ``py::class_ ``
136
- instantiations.
155
+ - Remove or replace (see below) ``std::shared_ptr<...> `` holders.
137
156
138
157
- Only if custom smart-pointers are used: the
139
- `PYBIND11_TYPE_CASTER_BASE_HOLDER ` macro is needed [` example
140
- <https://github.com/pybind/pybind11/blob/2f624af1ac8571d603df2d70cb54fc7e2e3a356a/ tests/test_multiple_inheritance .cpp#L72> `_] .
158
+ `PYBIND11_TYPE_CASTER_BASE_HOLDER ` macro is needed (see
159
+ tests/test_smart_ptr .cpp for examples) .
141
160
142
161
Overall this is probably easier to work with than the Conservative mode, but
143
162
144
163
- the macro inconvenience is shifted from ``py::smart_holder `` to custom
145
- smart-pointers (but probably much more rarely needed ).
164
+ smart-pointer holders (which are probably much more rare ).
146
165
147
166
- it will not interoperate with other extensions built against master or
148
167
stable, or extensions built in Conservative mode (see the cross-module
149
168
compatibility section below).
150
169
170
+ When migrating code that uses ``py::class_<Bar, std::shared_ptr<Bar>> `` there
171
+ are the same alternatives as for the Conservative mode (see previous section).
172
+ An additional alternative is to use the ``PYBIND11_SH_DEF(...) `` macro:
173
+
174
+ .. code-block :: diff
175
+
176
+ - py::class_<Bar, std::shared_ptr<Bar>>(m, "Bar");
177
+ + py::class_<Bar, PYBIND11_SH_DEF(Bar)>(m, "Bar");
178
+
179
+ The ``PYBIND11_SH_DEF `` macro substitutes ``py::smart_holder `` only in
180
+ Progressive mode, or ``std::shared_ptr<Bar> `` in Classic or Conservative
181
+ mode. See tests/test_classh_mock.cpp for an example. Note that the
182
+ ``PYBIND11_SMART_HOLDER_TYPE_CASTERS `` macro is never needed in combination
183
+ with the ``PYBIND11_SH_DEF `` macro, which is an advantage compared to the
184
+ ``PYBIND11_SH_AVL `` macro. Please review tests/test_classh_mock.cpp for a
185
+ concise overview of all available options.
186
+
151
187
152
- Transition from Conservative to Progressive mode
153
- ------------------------------------------------
188
+ Transition from Classic to Progressive mode
189
+ -------------------------------------------
154
190
155
191
This still has to be tried out more in practice, but in small-scale situations
156
192
it may be feasible to switch directly to Progressive mode in a break-fix
157
193
fashion. In large-scale situations it seems more likely that an incremental
158
194
approach is needed, which could mean incrementally converting ``py::class_ ``
159
- to ``py::classh `` including addition of the macros, then flip the switch,
160
- and convert ``py::classh `` back to ``py:class_ `` combined with removal of the
161
- macros if desired (at that point it will work equivalently either way). It
162
- may be smart to delay the final cleanup step until all third-party projects
163
- of interest have made the switch, because then the code will continue to
164
- work in either mode .
195
+ to ``py::classh `` and using the family of related macros, then flip the switch
196
+ to Progressive mode, and convert ``py::classh `` back to ``py:class_ `` combined
197
+ with removal of the macros if desired (at that point it will work equivalently
198
+ either way). It may be smart to delay the final cleanup step until all
199
+ third-party projects of interest have made the switch, because then the code
200
+ will continue to work in all modes .
165
201
166
202
167
- Using py::classh but with fallback to classic pybind11
168
- ------------------------------------------------------
203
+ Using py::smart_holder but with fallback to Classic pybind11
204
+ ------------------------------------------------------------
169
205
170
- This could be viewed as super-conservative mode, for situations in which
171
- compatibility with classic pybind11 (without smart_holder) is needed for
172
- some period of time. The main idea is to enable use of `` py::classh ``
173
- and the associated `` PYBIND11_SMART_HOLDER_TYPE_CASTERS `` macro while
174
- still being able to build the same code with classic pybind11. Please see
175
- tests/test_classh_mock.cpp for an example .
206
+ For situations in which compatibility with Classic pybind11
207
+ (without smart_holder) is needed for some period of time, fallback
208
+ to Classic mode can be enabled by copying the `` BOILERPLATE `` code
209
+ block from tests/test_classh_mock.cpp. This code block provides mock
210
+ implementations of `` py::classh `` and the family of related macros
211
+ (e.g. `` PYBIND11_SMART_HOLDER_TYPE_CASTERS ``) .
176
212
177
213
178
214
Classic / Conservative / Progressive cross-module compatibility
@@ -268,7 +304,7 @@ inherit from ``py::trampoline_self_life_support``, for example:
268
304
...
269
305
};
270
306
271
- This is the only difference compared to classic pybind11. A fairly
307
+ This is the only difference compared to Classic pybind11. A fairly
272
308
minimal but complete example is tests/test_class_sh_trampoline_unique_ptr.cpp.
273
309
274
310
@@ -277,7 +313,7 @@ Ideas for the long-term
277
313
278
314
The macros are clearly an inconvenience in many situations. Highly
279
315
speculative: to avoid the need for the macros, a potential approach would
280
- be to combine the classic implementation (``type_caster_base ``) with
316
+ be to combine the Classic implementation (``type_caster_base ``) with
281
317
the ``smart_holder_type_caster ``, but this will probably be very messy and
282
318
not great as a long-term solution. The ``type_caster_base `` code is very
283
319
complex already. A more maintainable approach long-term could be to work
0 commit comments