How to detect NULL for boost:shared_ptr

[tradevol]

Hi,

I am playing with boost pointer and try to wrap the following codes

A* func(){
...
if(condition 1 ){
return a;
}
else
return NULL;

}

Now I wrap a as shared_ptr(new A()) and change funcion as share_ptr<A>
func();
The problem is that shared_ptr will not accept NULL.

How should I do it in this case?

Thanks

Chris

 

[Thomas J. Gritzan]

Hi,

I am playing with boost pointer and try to wrap the following codes

A* func(){
...
if(condition 1 ){
return a;
}
else
return NULL;

}

Now I wrap a as shared_ptr(new A()) and change funcion as share_ptr<A>
func();
The problem is that shared_ptr will not accept NULL.

How should I do it in this case?

Did you try to return a default-constructed pointer like this?

return shared_ptr<A>();

 

[sylvester.zaluga]

(e-mail address removed) schrieb:







Did you try to return a default-constructed pointer like this?

   return shared_ptr<A>();

Well, I don't know exactly what you mean, since shared_ptr is there to
avoid the ordinary pointers. However, if I understand correctly what
this is all about you can do it this way:

shared_ptr<A> func()
{
shared_ptr<A> r; //automatically set to point to NULL
if(condition 1 )
{
shared_ptr<A> r(new A);
return r; //I read somewhere to avoid creating new shared_ptrs
"on the fly" like "return shared_ptr<A>(new A);"
}
else
{
shared_ptr<A> r; //set to point to NULL automatically
return r;
}

}

// ... and then, somewhere in code:
shared_ptr<A> test = func();
if(test.get() == NULL)
do sth



I hope it helps...

 

[tradevol]

Well, I don't know exactly what you mean, since shared_ptr is there to
avoid the ordinary pointers. However, if I understand correctly what
this is all about you can do it this way:

shared_ptr<A> func()
{
   shared_ptr<A> r; //automatically set to point to NULL
   if(condition 1 )
   {
      shared_ptr<A> r(new A);
      return r; //I read somewhere to avoid creating new shared_ptrs
"on the fly" like "return shared_ptr<A>(new A);"
  }
  else
 {
     shared_ptr<A> r; //set to point to NULL automatically
     return r;
 }

}

// ... and then, somewhere in code:
shared_ptr<A> test = func();
if(test.get() == NULL)
    do sth

I hope it helps...

yes. This what I asked for. sorry for the confusion.
Thank you very much

 

[Noah Roberts]

shared_ptr<A> func()
{
shared_ptr<A> r; //automatically set to point to NULL
if(condition 1 )
{
shared_ptr<A> r(new A);

This is an unnecessary stack variable. Same with below. You can call
reset(T * p) to assign to the pointer declared in function scope.

 

[Michael DOUBEZ]

(e-mail address removed) a écrit :

return r; //I read somewhere to avoid creating new shared_ptrs
"on the fly" like "return shared_ptr<A>(new A);"

It is bad practice to use unnamed shared_ptr in parameters because the
order of evaluation of parameters is unspecified.
But it does not matter in this case; if you have a ressource shortage,
the shared_ptr<>'s constructor deletes its parameter before throwing
bad_alloc and no memory leak occurs.

 

[James Kanze]

(e-mail address removed) a écrit :

It is bad practice to use unnamed shared_ptr in parameters
because the order of evaluation of parameters is unspecified.

Except that the above isn't a paremeter, but a return value.

But it does not matter in this case; if you have a ressource
shortage, the shared_ptr<>'s constructor deletes its parameter
before throwing bad_alloc and no memory leak occurs.

That doesn't change anything. If the function takes two
shared_ptr, and you want to pass it something like:
f( shared_ptr<X>( new X ), shared_ptr<Y>( new Y ) ) ;
, you can still get a resource link.

 

[James Kanze]

I am playing with boost pointer and try to wrap the following codes

A* func(){
...
if(condition 1 ){
return a;
}
else
return NULL;
}

Now I wrap a as shared_ptr(new A()) and change funcion as share_ptr<A>
func();
The problem is that shared_ptr will not accept NULL.

Are you sure? I've not much experience with boost::shared_ptr,
but all of the smart pointers I've use do accept constructing
them with NULL.

How should I do it in this case?

In this particular case, I'd probably write something like:

shared_ptr< A >
func()
{
return shared_ptr< A >(
someCondition
? new A
: NULL ) ;
}

In more complicated cases, however:

shared_ptr< A >
func()
{
shared_ptr< A > result ;
if ( someCondition ) {
result = new A ;
}
return result ;
}

I'd be very surprised if either of them failed to work with
boost::shared_ptr. Just as I'd be very surprised if, given the
definition of result, above "result = NULL ;" wouldn't compile;
for that matter, there's no reason why "if ( result == NULL )"
can't be made to work as expected, either.

 

[Michael DOUBEZ]

James Kanze a écrit :

Except that the above isn't a paremeter, but a return value.

My point exactly; although I didn't express it clearly.

That doesn't change anything. If the function takes two
shared_ptr, and you want to pass it something like:
f( shared_ptr<X>( new X ), shared_ptr<Y>( new Y ) ) ;
, you can still get a resource link.

In the case of the OP, it is in a return statement and we was careful to
avoid unnamed shared_ptr<>.

<quote>
//I read somewhere to avoid creating new shared_ptrs "on the fly" like
"return shared_ptr<A>(new A);"
</quote>

I wanted to mention that it is safe to do so:
return shared_ptr<A>(new A);

 

[James Kanze]

On 2008-08-05 04:17:07 -0400, James Kanze <[email protected]> said:

Yes, it's a problem. The constructor that takes a raw pointer
is a template:

template <class T> class shared_ptr {
template <class Y> explicit shared_ptr(Y *p);
...
};

And there's not a non-templated version alongside of it?
Sounds like something got forgotten along the way.

with a requirement that Y* must be convertible to T*. So a
normal null pointer doesn't work. For a shared_ptr<int> you
have to use something like (int*)0, or use the default
constructor.

But it would be easy to add a constructor which would work with
NULL. Which is what most users would expect.

Hmmm. I don't see in Boost documentation where they support
comparison with NULL, either. Which would seem a rather
frequent operation, and certainly necessary if you're doing like
the original poster, and converting from raw pointers.

 

[James Kanze]

You may not be able to compare to NULL explicitly (this is unconfirmed by
me), but shared_ptr has the operator unspecified_bool_type( ) so you can
test the pointer directly, so it's really not that big a deal (OTHER than
the fact that a shared_ptr is not syntactically a "drop-in" replacement for
a conventional pointer).

shared_ptr< MyClass > myVar = func( );

if( myVar ) // is the pointer not null?
DoSomething( );

In other words, it supports the misfeatures of standard
pointers, but not the correct way of using them. (Obviously,
if you're going to call it a smart pointer, you have to support
the misfeatures as well. But not supporting the standard idiom
is simply not acceptable.)