[C++-sig] Transfer of ownership

[David Abrahams]

Eric Jardim <ericjardim at gmail.com> writes:

> Hi, all...
>
> This is a simple question. I was reading the docs where it says about the 
> "transfer of ownership" of a C++ object pointer. I am dealing exacly this 
> situation, where the "with_custodian_and_ward" policy is not enough to 
> prevent Python objects to delete C++ couterparts. The only hack is to hold 
> references, but it is not a complete solution.
>
> So, I read the FAQ entry where it explain how to deal with this issue:
> http://www.boost.org/libs/python/doc/v2/faq.html#ownership
>
> But there, it speaks about using an "std::auto_ptr". On the other side, I am 
> using "boost::shared_ptr" to hold my objects. I really do not know the 
> difference between them, but I imagine they provide similar
> funcionality. 

Yes, similar, but auto_ptr provides exclusive, as opposed to shared,
ownership semantics.  When an auto_ptr is copied or assigned, the
source loses ownership and the destination acquires it.

> So I will split my question in 3 parts:
> - Is it possible to take the ownership with "boost::shared_ptr", 

Not if you mean to substitute it in the example in the FAQ, no.

> or do I have to change my held types to "std::auto_ptr"?

That's a completely separate question.  No, you don't need to change
your held types.

> - Is there any difference in practice, using boost's or std's smart 
> pointers? 

Yes, there are lots of differences.  However you haven't been very
specific about what you're interested in; you'd have to read the
documentation for each of them to grasp all of the differences.

> I just use them for holding Boost.Python extensions.

> - As those functions with smart pointers do not exists, I suppose
> that I will have to write wrappers like:
>
> void b_insert(B& b, std::auto_ptr<A> a)
> {
>     b.insert(a.get());
>     a.release();
> }
>
> Is there any special reason for this to be a non-const reference to
> "b"? 

Yes, all free functions that are going to be wrapped as class methods
should take a non-const reference as their first argument.
 
> Could it be a const reference

That would allow an implicit conversion from some other type to B to
take place when calling the method, since const references can bind to rvalues

> or a const/non-const pointer to "b"? 

That would allow None to be passed as the first argument, resulting in
a NULL pointer.

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