Boost logo

Boost Users :

From: Per Ghosh (per_at_[hidden])
Date: 2008-03-25 07:33:06


As I understand it (been working with boost-python for two weeks) so:

returning a pointer by  "return_value_policy<reference_existing_object>()" and that pointer will not be managed by python (not deleted)

returning a pointer by  "return_value_policy<manage_new_object>()" and that pointer will be managed by python. It will be deleted by python.

I order to return a pointer to python, the pointer should point to a known object (declared within the BOOST_PYTHON_MODULE macro)


Robert Dailey skrev:
Hi,

I had a bit of trouble deciding which mailing list to post this question (Python or boost). I decided to post it here since the way I'm extending is boost-specific, however the fundamental question is in regards to how Python internally handles ownership. I do not feel there is a perfect location for this question, so I hope you'll forgive the semi-off topicness of the question.

Right now I'm exposing a function to Python that returns a pointer to a custom object owned by a third party library. In most cases I can manage to use boost::shared_ptr when I'm returning pointers, however since this is a third party library I cannot do this. Since the pointer I'm returning is owned and managed by another object, I gave my def() the following return policy:

return_value_policy<reference_existing_object>()

I simply assumed this was correct. How does Python handle the pointer to this object? Is there some documents in either boost or the python documentation that I can read to understand a little more about how Python handles object ownership when the Python objects really represent C++ pointers? Perhaps someone could give me a brief rundown on the concept.

Thanks in advance.

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net