Add std::unique_ptr support

[jorisv]

• Add a CallPolicy to copy the content of a std::unique_ptr for function return
• Add a CallPolicy to move the content of a std::unique_ptr for function return
• Add a CallPolicy to get a reference of the content of a std::unique_ptr for member access
• Specialize to_python_value

Fix #427

[jorisv]

In the current solution, when a function binding that return a std::unique_ptr is defined, the StdUniquePtrCallPolicies must be used.

It's maybe possible to overload boost::python::to_python_value to manage unique_ptr in the boost::python::default_call_policy.
In this case, before defining a function binding that return a std::unique_ptr user should include eigenpy/std_unique_ptr.hpp.

I don't know if the second option is better. User have less code to write, but he should include the right header that will do some magic for him.

@ManifoldFR, @jcarpent Any opinion ? (Not an emergency)

[ManifoldFR]

In the current solution, when a function binding that return a std::unique_ptr is defined, the StdUniquePtrCallPolicies must be used.

It's maybe possible to overload boost::python::to_python_value to manage unique_ptr in the boost::python::default_call_policy. In this case, before defining a function binding that return a std::unique_ptr user should include eigenpy/std_unique_ptr.hpp.

I don't know if the second option is better. User have less code to write, but he should include the right header that will do some magic for him.

@ManifoldFR, @jcarpent Any opinion ? (Not an emergency)

Both solutions seem sound to me.

If we go for an overload of to_python_value we could just include <eigenpy/std_unique_ptr.hpp> in <eigenpy/eigenpy.hpp> to avoid user error?

[jorisv]

If we go for an overload of to_python_value we could just include <eigenpy/std_unique_ptr.hpp> in <eigenpy/eigenpy.hpp> to avoid user error?

It would be the safest option.

I will investigate this solution then.

It's not possible to do the same thing with return_internal_reference because the structure only deal with reference or ptr (assert in reference_existing_object).

[ManifoldFR]

If we go for an overload of to_python_value we could just include <eigenpy/std_unique_ptr.hpp> in <eigenpy/eigenpy.hpp> to avoid user error?

It would be the safest option.

I will investigate this solution then.

It's not possible to do the same thing with return_internal_reference because the structure only deal with reference or ptr (assert in reference_existing_object).

Would it be possible to do it on with_custodian_and_ward then ? Or does it still refer to reference_existing_object

[ManifoldFR]

This is fantastic @jorisv, thanks a lot

I have a few questions:

• whether bp::register_ptr_to_python can be used anywhere here as a shortcut,
• whether unique_ptr can be used as a holder class (an argument in the bp::class_ template, the docs say one could expose a type T through shared_ptr<T> for instance) ; this is something Pybind11 does by default and I'm not sure whether boost.python already does that
• whether vector<unique_ptr<T>> can be exposed

[jorisv]

Would it be possible to do it on with_custodian_and_ward then ? Or does it still refer to reference_existing_object

Ok, it's mandatory to define a new Policies. We can't specialize bp::return_internal_reference (it doesn't depend of the type). But we need to redefine his postcall method.

[jorisv]

* whether `bp::register_ptr_to_python` can be used anywhere here as a shortcut,

I don't know, it look like it doesn't manage the move like we are doing for unique_ptr.

* whether `unique_ptr` can be used as a holder class (an argument in the `bp::class_` template, the docs say one could expose a type `T` through `shared_ptr<T>` for instance) ; this is something Pybind11 [does by default](https://pybind11.readthedocs.io/en/stable/advanced/smart_ptrs.html) and I'm not sure whether boost.python already does that

When we transfer the ownership to python (return value) the bp::detail::make_owning_holder store the pointer in an unique_ptr.
I have change the method to directly call bp::objects::make_ptr_instance<T, holder_t> so we don't have to call unique_ptr::release.

* whether `vector<unique_ptr<T>>` can be exposed

We have modify the std::vector binding to manage non copiable data

[ManifoldFR]

* whether `bp::register_ptr_to_python` can be used anywhere here as a shortcut,

I don't know, it look like it doesn't manage the move like we are doing for unique_ptr.

OK, make sense. register_ptr_to_python probably wasn't revamped with move semantics in mind.

* whether `unique_ptr` can be used as a holder class (an argument in the `bp::class_` template, the docs say one could expose a type `T` through `shared_ptr<T>` for instance) ; this is something Pybind11 [does by default](https://pybind11.readthedocs.io/en/stable/advanced/smart_ptrs.html) and I'm not sure whether boost.python already does that

When we transfer the ownership to python (return value) the bp::detail::make_owning_holder store the pointer in an unique_ptr. I have change the method to directly call bp::objects::make_ptr_instance<T, holder_t> so we don't have to call unique_ptr::release.

After checking we saw that unique_ptr is somewhat the default holder in Boost.Python as well.
I guess calling make_ptr_instance allows to having a leak in case an exception is triggered, so that's a good change!

[ManifoldFR]

Best PR ever