[C++-sig] express pointer ownership

[MM]

On 13 August 2015 at 12:01, Stefan Seefeld <stefan at seefeld.name> wrote:

> On 13/08/15 06:58 AM, MM wrote:
> > On 13 August 2015 at 10:24, MM <finjulhich at gmail.com
> > <mailto:finjulhich at gmail.com>> wrote:
> >
> >     I have the following class:
> >
> >     class T {
> >     };
> >     // T has been exposed to python with class_
> >
> >     and free function:
> >
> >     void add_T( T* );
> >
> >     Ownership of the T* is taken by this C++ function.
> >
> >
> >     If I create an instance of the python version of T, how do I "def"
> >     the add_T function?
> >
> >     def("add_T", add_T)
> >
> >     fails to compile.
> >
> >
> > Apologies. This compiled correctly.
> >
> > This function:
> >
> > const T* get_T( const std::string& name );
> >
> > failed to compile.
> >
> > so the T pointer is owner by a container in the c++ world, it gets
> > stored there by add_T,
> > then the get_T  returns a raw pointer to it. I want to tell python to
> > let c++ manage it.
>
> Sounds like you want to use the "return_internal_reference" call policy
> (see
>
> http://boostorg.github.io/python/doc/html/tutorial/tutorial/functions.html#tutorial.functions.call_policies
> ).
>
>         Stefan
>
>
That policy says:

"Ties lifetime of one argument to that of result"

The argument of my function is just the string.... Really its lifetime
doesn't matter....
In the context of a call from python:

t = get_T( 'name1' )

At some point, a std::string temporary must be constructed, holding
'name1'?  and then get_T uses it for lookup.
Once get_T returns   the const T*, it doesn't care about it anymore.

What I want to express is:

The t returned by the python function should refer to object T held in c++
memory, and for instance

del t

should not delete the actual T object in c++ memory

Should I still use "return_internal_reference"  ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20150813/63b033c1/attachment.html>