On 13 August 2015 at 12:01, Stefan Seefeld <ste...@seefeld.name> wrote:
> On 13/08/15 06:58 AM, MM wrote: > > On 13 August 2015 at 10:24, MM <finjulh...@gmail.com > > <mailto:finjulh...@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" ?
_______________________________________________ Cplusplus-sig mailing list Cplusplus-sig@python.org https://mail.python.org/mailman/listinfo/cplusplus-sig
