In practice, type_caster_holder<T> demands T to be copy constructible #5142
Replies: 1 comment
-
|
Just as an example, in the case of pybind11/include/pybind11/cast.h Lines 831 to 833 in 86a6429 That is, even if As the following comment explains, pybind11/include/pybind11/cast.h Lines 835 to 849 in 86a6429 This comment is also relevant: pybind11/include/pybind11/cast.h Lines 750 to 756 in 86a6429 All this, to support the fact that we should use STL's pybind11/include/pybind11/cast.h Line 855 in 86a6429 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I think it is a bug. But the "issue tracker" encouraged me to discuss it here, first. :-)
The
type_caster_holder<T>type is defined like this:I think that using the non STL
is_copy_constructibleis wrong, here. The correct would bestd::is_copy_constructible, instead. The reason is that the former is a "recursive check" for copy constructiveness. That is, for example,std::shared_ptr<NoCopyType>will not be considered copyable ifNoCopyTypeis not.Maybe this is the reason
std::shared_ptr<T>is treated specially inPYBIND11_DECLARE_HOLDER_TYPE.My custom shared ptr was not compiling because it was being treated as "move only". By using
std::is_copy_constructible, it now compiles.Am I missing something? Shall I submit a PR?
Beta Was this translation helpful? Give feedback.
All reactions