Controlling/releasing ownership in shared_ptr

[digz]

In the code below , a simplified version
I need to pass a smart pointer to function f which I control .I
cannot use std::auto_ptr as a parameter to f because
it releases ownership on copy construction and I still need the
pointer after f returns.( may be I could return the auto_ptr
again ?? )

after f does its stuff , i need to pass it to g which expects a raw
pointer ( I cannot change that API )
I know g does maintain its own ptr_deque which takes care of
ownership etc.. ,

I am forced to do a get() on the shared_ptr ( instead of an ideal
release() on auto_ptr which would free the ptr from smart
management )
Now shared_ptr and ptr_deque desturctors cause a double delete
leading to UB.
How do i workaround this problem ?

Thx
Digz

#include<boost/shared_ptr.hpp>
#include<boost/ptr_container/ptr_deque.hpp>

boost:tr_deque<int> l;

void f(boost::shared_ptr<int> t = boost::shared_ptr<int>())
{}

void g(int* i){
l.push_back(i);
}

int h(){
boost::shared_ptr<int> i(new int);
f(i); //need to pass aroung i, so cant use std::auto_ptr
g(i.get()); //cant release from boost::shared_ptr ownership
}

int main(){
h();
}

 

[Alf P. Steinbach]

* digz:

In the code below , a simplified version
I need to pass a smart pointer to function f which I control .I
cannot use std::auto_ptr as a parameter to f because
it releases ownership on copy construction and I still need the
pointer after f returns.( may be I could return the auto_ptr
again ?? )

after f does its stuff , i need to pass it to g which expects a raw
pointer ( I cannot change that API )
I know g does maintain its own ptr_deque which takes care of
ownership etc.. ,

I am forced to do a get() on the shared_ptr ( instead of an ideal
release() on auto_ptr which would free the ptr from smart
management )
Now shared_ptr and ptr_deque desturctors cause a double delete
leading to UB.
How do i workaround this problem ?

#include<boost/shared_ptr.hpp>
#include<boost/ptr_container/ptr_deque.hpp>

boost:tr_deque<int> l;

"l" is not a good name because it's easily confused with "1".

void f(boost::shared_ptr<int> t = boost::shared_ptr<int>())
{}

void g(int* i){
l.push_back(i);
}

int h(){
boost::shared_ptr<int> i(new int);
f(i); //need to pass aroung i, so cant use std::auto_ptr
g(i.get()); //cant release from boost::shared_ptr ownership
}

You can use std::auto_ptr for exception safety and ownership transfer.

Off-the-cuff, fix errors if any:

void f( int& ) {}

void transferOwnershipToG( std::auto_ptr<int> p )
{
int* pRaw = p.get();
p.release();
g( pRaw );
}

int h()
{
std::auto_ptr<int> p( new int );
f( *p ); // If f throws, std::auto_ptr deallocates.
transferOwnershipToG( p );
}

Or, with the current boost::shared_ptr interface you can release a
boost::shared_ptr by replacing its delete function. I think the
function to gain access to the deleter is named get_deleter. However,
this could be a bit dangerous, because with a shared_ptr at hand one
expects that it will handle deallocation and can be copied and stored
safely, which will not be the case in your code.

Cheers, & hth.,

- Alf

 

[James Kanze]

* digz:

[...]

Off-the-cuff, fix errors if any:

void f( int& ) {}

void transferOwnershipToG( std::auto_ptr<int> p )
{
int* pRaw = p.get();
p.release();
g( pRaw );
}

Generally, I would do the release after the call to g(), i.e.:
g( p.get() ) ;
p.release() ;
Only if the call to g() succeeds can I be sure that it has taken
over ownership. Otherwise, you can just call g() directly:
g( p.release() ) ;

(Obviously, this depends partially on g(). Normally, in the
absence of other documentation, I would expect transactional
semantics, which means that if g() returns via an exception,
nothing has changed, and I am still responsible for the object.
But it's something I'd verify anyway.)

 

[Alf P. Steinbach]

* James Kanze:

* digz:
[...]
Off-the-cuff, fix errors if any:

void f( int& ) {}

void transferOwnershipToG( std::auto_ptr<int> p )
{
int* pRaw = p.get();
p.release();
g( pRaw );
}

Generally, I would do the release after the call to g(), i.e.:
g( p.get() ) ;
p.release() ;

Yup. I had a feeling there was something.

Only if the call to g() succeeds can I be sure that it has taken
over ownership. Otherwise, you can just call g() directly:
g( p.release() ) ;

Yup again -- otherwise no reason for having the transferOwnershipToG
wrapper.

(Obviously, this depends partially on g(). Normally, in the
absence of other documentation, I would expect transactional
semantics, which means that if g() returns via an exception,
nothing has changed, and I am still responsible for the object.
But it's something I'd verify anyway.)

Code above assumed failure reporting via exceptions.

Cheers,

- Alf