[C++-sig] Ownership question.

[David Abrahams]

tALSit de CoD <talsit at talsit.org> writes:

> Ok, I think i got ya, but I think that's not what I was saying.
>
> When I do this:
>
>  >>> key = cAnimCurveKey ()
>
> Python is in charge of the ownership of the object. So, in theory, the
> GC could mark it for collection at any given moment, right?

Well, not until all the (strong) references are gone, but yes.

> So if I now add the key to a class that takes it's ownership

[I assume you mean by accepting a std::auto_ptr<cAnimCurveKey>
argument...]

> what happens?

The C++ part of the object gets detached from the Python part and
animCurve manages the C++ part.

>  >>> animCurve.addKey (key)  # animCurve is now in charge of deleting the key
>
> is key still managed by python? 

The one you see in Python is.  You can't do much with it, though,
since it's lost its C++ data.  Try it; you'll get a "friendly"
traceback.

> Will it be marked for collection by the GC?

Actually, Boost.Python objects are not GC-enabled.  It's really too
dangerous since we can't be guaranteed of being able to trace all the
references they hold to Python objects (e.g. the C++ class might embed
a boost::python::object, or even a shared_ptr<> which is keeping a
Python object alive).  However, I don't think you're really interested
in GC, since plenty of objects get destroyed by Python just due to its
reference-counting, before GC ever kicks in.  GC in Python is really
only for collecting reference cycles.

> If so, how do i prevent it?

I doubt this question is still relevant given what I've said above,
but if I'm wrong, please ask again.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com