468,512 Members | 1,382 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,512 developers. It's quick & easy.

boost::shared_ptr - NULL

If a method is declared to return a type boost::shared_ptr<sometype>,
how can the method be changed to do the equivalent of returning NULL
when it was declared to return a raw pointer?

Dec 1 '07 #1
9 9393
On Sat, 1 Dec 2007 11:36:51 -0800 (PST) in comp.lang.c++,
Christopher <cp***@austin.rr.comwrote,
>Are you referring to the boost manual?
http://www.boost.org/libs/smart_ptr/scoped_ptr.htm

I did and all I see is a reset function which sets the internal
pointer to NULL, but it doesn't say how to check if it is NULL,
How about
if (retvalue == boost::shared_ptr<sometype>()) {

Think!
>and it
says that behavior is undefined if you dereference it while the
internal pointer is NULL.
Yes, don't do that.

Dec 1 '07 #2
On Dec 1, 9:19 pm, David Harmon <sou...@netcom.comwrote:
On Sat, 1 Dec 2007 11:36:51 -0800 (PST) in comp.lang.c++,
Christopher <cp...@austin.rr.comwrote,
Are you referring to the boost manual?
http://www.boost.org/libs/smart_ptr/scoped_ptr.htm
I did and all I see is a reset function which sets the internal
pointer to NULL, but it doesn't say how to check if it is NULL,
How about
if (retvalue == boost::shared_ptr<sometype>()) {
How about:
if ( retvalue == NULL ) { ... }

I've not looked at boost::shared_ptr in this regard, but all of
the intelligent pointers I've written accept it.

In practice, if I think there's the slightest chance of using
intelligent pointers, I'll write something like:

template< typename T >
bool
isValid( T const* p )
{
return p != NULL ;
}

and use it. Adding the necessary overloads for the intelligent
pointers as needed. (This allows easily switching back, when
you realize that the smart pointer doesn't work.) But as I
said, a correctly designed intelligent pointer should support
all of the idioms a raw pointer does: "if( ptr == NULL )", and
even "if ( ptr )" (although I've never seen a coding guideline
that would allow use of the latter).

And if worse comes to worse, there's always:
if ( ptr.get() == NULL ) ...

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Dec 2 '07 #3
On Dec 1, 12:19 pm, David Harmon <sou...@netcom.comwrote:
On Sat, 1 Dec 2007 11:36:51 -0800 (PST) in comp.lang.c++,
Christopher <cp...@austin.rr.comwrote,
Are you referring to the boost manual?
http://www.boost.org/libs/smart_ptr/scoped_ptr.htm
I did and all I see is a reset function which sets the internal
pointer to NULL, but it doesn't say how to check if it is NULL,

How about
if (retvalue == boost::shared_ptr<sometype>()) {
How about the more succinct:

if (not retval) {

or, alternately:

if (retval == false) {

Greg
Dec 3 '07 #4
James Kanze a écrit :
On Dec 1, 9:19 pm, David Harmon <sou...@netcom.comwrote:
>On Sat, 1 Dec 2007 11:36:51 -0800 (PST) in comp.lang.c++,
Christopher <cp...@austin.rr.comwrote,
>>Are you referring to the boost manual?
http://www.boost.org/libs/smart_ptr/scoped_ptr.htm
>>I did and all I see is a reset function which sets the internal
pointer to NULL, but it doesn't say how to check if it is NULL,
>How about
if (retvalue == boost::shared_ptr<sometype>()) {

How about:
if ( retvalue == NULL ) { ... }

I've not looked at boost::shared_ptr in this regard, but all of
the intelligent pointers I've written accept it.
Boost share_ptr doesn't provide a operator==(smart_ptr<T>& smart,T*ptr).

I could not find the exact reason in the original proposal but I guess
it is an efficiency matter: it would be equivalent to
'(smart.use_count()?smart.ptr:NULL) == ptr' when the intended operations
in the case ptr=NULL would have been '(use_count()==0) ||
(smart.ptr==NULL)'.
>
In practice, if I think there's the slightest chance of using
intelligent pointers, I'll write something like:

template< typename T >
bool
isValid( T const* p )
{
return p != NULL ;
}

and use it. Adding the necessary overloads for the intelligent
pointers as needed. (This allows easily switching back, when
you realize that the smart pointer doesn't work.) But as I
said, a correctly designed intelligent pointer should support
all of the idioms a raw pointer does: "if( ptr == NULL )", and
even "if ( ptr )" (although I've never seen a coding guideline
that would allow use of the latter).

And if worse comes to worse, there's always:
if ( ptr.get() == NULL ) ...
But smart-ptr does provide conversion to unspecified-bool-type.

The doc is quite explicit:

*conversions*

operator unspecified-bool-type () const; // never throws

Returns: an unspecified value that, when used in boolean contexts,
is equivalent to get() != 0.

Throws: nothing.

Notes: This conversion operator allows shared_ptr objects to be
used in boolean contexts, like if (p && p->valid()) {}. The actual
target type is typically a pointer to a member function, avoiding many
of the implicit conversion pitfalls.

[The conversion to bool is not merely syntactic sugar. It allows
shared_ptrs to be declared in conditions when using dynamic_pointer_cast
or weak_ptr::lock.]

Michael
Dec 3 '07 #5
On Dec 3, 6:36 am, Michael DOUBEZ <michael.dou...@free.frwrote:
James Kanze a écrit :
On Dec 1, 9:19 pm, David Harmon <sou...@netcom.comwrote:
On Sat, 1 Dec 2007 11:36:51 -0800 (PST) in comp.lang.c++,
Christopher <cp...@austin.rr.comwrote,
>Are you referring to the boost manual?
http://www.boost.org/libs/smart_ptr/scoped_ptr.htm
>I did and all I see is a reset function which sets the internal
pointer to NULL, but it doesn't say how to check if it is NULL,
How about
if (retvalue == boost::shared_ptr<sometype>()) {
How about:
if ( retvalue == NULL ) { ... }
I've not looked at boost::shared_ptr in this regard, but all of
the intelligent pointers I've written accept it.
Boost share_ptr doesn't provide a operator==(smart_ptr<T>& smart,T*ptr).
I'm not sure that that's what is wanted. In my own smart
pointers, I use something like:

template< typename T >
class SmartPtr
{
struct Hidden {} ;
public:
// ...
friend operator==( SmartPtr< T const&, Hidden const* ) ;
friend operator!=( Hidden const*, SmartPtr< T const& ) ;
// ...
} ;

Null pointer constants convert to Hidden const*, but the user
can't get one any other way.
I could not find the exact reason in the original proposal but I guess
it is an efficiency matter: it would be equivalent to
'(smart.use_count()?smart.ptr:NULL) == ptr' when the intended operations
in the case ptr=NULL would have been '(use_count()==0) ||
(smart.ptr==NULL)'.
I can't really believe that the difference in efficiency would
make a difference here.
In practice, if I think there's the slightest chance of using
intelligent pointers, I'll write something like:
template< typename T >
bool
isValid( T const* p )
{
return p != NULL ;
}
and use it. Adding the necessary overloads for the intelligent
pointers as needed. (This allows easily switching back, when
you realize that the smart pointer doesn't work.) But as I
said, a correctly designed intelligent pointer should support
all of the idioms a raw pointer does: "if( ptr == NULL )", and
even "if ( ptr )" (although I've never seen a coding guideline
that would allow use of the latter).
And if worse comes to worse, there's always:
if ( ptr.get() == NULL ) ...
But smart-ptr does provide conversion to unspecified-bool-type.
Yes. But this forces you do use something like:

if( ptr ) ...

Gratuous obfuscation, and forbidden by all of the coding
guidelines I've seen. (Never the less, I'd support it as well.
Because raw pointers do.)

Of course, from a QoI point of view, you wouldn't use bool, but
"Hidden const*", to avoid any chance of mis-use.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Dec 3 '07 #6
James Kanze a écrit :
On Dec 3, 6:36 am, Michael DOUBEZ <michael.dou...@free.frwrote:
>James Kanze a écrit :
>>On Dec 1, 9:19 pm, David Harmon <sou...@netcom.comwrote:
On Sat, 1 Dec 2007 11:36:51 -0800 (PST) in comp.lang.c++,
Christopher <cp...@austin.rr.comwrote,
Are you referring to the boost manual?
http://www.boost.org/libs/smart_ptr/scoped_ptr.htm
I did and all I see is a reset function which sets the internal
pointer to NULL, but it doesn't say how to check if it is NULL,
How about
if (retvalue == boost::shared_ptr<sometype>()) {
How about:
if ( retvalue == NULL ) { ... }
I've not looked at boost::shared_ptr in this regard, but all of
the intelligent pointers I've written accept it.
>Boost share_ptr doesn't provide a operator==(smart_ptr<T>& smart,T*ptr).

I'm not sure that that's what is wanted. In my own smart
pointers, I use something like:

template< typename T >
class SmartPtr
{
struct Hidden {} ;
public:
// ...
friend operator==( SmartPtr< T const&, Hidden const* ) ;
friend operator!=( Hidden const*, SmartPtr< T const& ) ;
// ...
} ;

Null pointer constants convert to Hidden const*, but the user
can't get one any other way.
Yes. Unless T is void but I guess it doesn't happen often.
Michael
Dec 3 '07 #7
On Dec 3, 2:39 pm, James Kanze <james.ka...@gmail.comwrote:
On Dec 3, 6:36 am, Michael DOUBEZ <michael.dou...@free.frwrote:
But smart-ptr does provide conversion to unspecified-bool-type.

Yes. But this forces you do use something like:

if( ptr ) ...

Gratuous obfuscation, and forbidden by all of the coding
guidelines I've seen. (Never the less, I'd support it as well.
Because raw pointers do.)

Of course, from a QoI point of view, you wouldn't use bool, but
"Hidden const*", to avoid any chance of mis-use.
Why is it a forbidden guideline? What possible mis-use can this be?
Dec 3 '07 #8
Abhishek Padmanabh a écrit :
On Dec 3, 2:39 pm, James Kanze <james.ka...@gmail.comwrote:
>On Dec 3, 6:36 am, Michael DOUBEZ <michael.dou...@free.frwrote:
>>But smart-ptr does provide conversion to unspecified-bool-type.
Yes. But this forces you do use something like:

if( ptr ) ...

Gratuous obfuscation, and forbidden by all of the coding
guidelines I've seen. (Never the less, I'd support it as well.
Because raw pointers do.)

Of course, from a QoI point of view, you wouldn't use bool, but
"Hidden const*", to avoid any chance of mis-use.

Why is it a forbidden guideline? What possible mis-use can this be?
The misuse can come from implicit conversion.
In the case of smart pointer, if the implicit conversion was bool:
shared_ptr<Foobar;
int f=bar;

This would not be detected by the compiler because bar is implicitely
converter to bool which is promoted to int. The usual solution is to use
a pointer on member function, it is pretty safe.

Now concerning the guidelines, I always use the ==NULL notation because
the notation is more easier for me to read and it indicates me it is a
pointer that is compared. There may be other issues.

Michael
Dec 3 '07 #9
On Dec 3, 2:20 pm, Michael DOUBEZ <michael.dou...@free.frwrote:
James Kanze a écrit :
On Dec 3, 6:36 am, Michael DOUBEZ <michael.dou...@free.frwrote:
James Kanze a écrit :
On Dec 1, 9:19 pm, David Harmon <sou...@netcom.comwrote:
On Sat, 1 Dec 2007 11:36:51 -0800 (PST) in comp.lang.c++,
Christopher <cp...@austin.rr.comwrote,
Are you referring to the boost manual?
http://www.boost.org/libs/smart_ptr/scoped_ptr.htm
I did and all I see is a reset function which sets the internal
pointer to NULL, but it doesn't say how to check if it is NULL,
How about
if (retvalue == boost::shared_ptr<sometype>()) {
How about:
if ( retvalue == NULL ) { ... }
I've not looked at boost::shared_ptr in this regard, but all of
the intelligent pointers I've written accept it.
Boost share_ptr doesn't provide a operator==(smart_ptr<T>& smart,T*ptr).
I'm not sure that that's what is wanted. In my own smart
pointers, I use something like:
template< typename T >
class SmartPtr
{
struct Hidden {} ;
public:
// ...
friend operator==( SmartPtr< T const&, Hidden const* ) ;
friend operator!=( Hidden const*, SmartPtr< T const& ) ;
// ...
} ;
Null pointer constants convert to Hidden const*, but the user
can't get one any other way.
Yes. Unless T is void but I guess it doesn't happen often.
Good point. That might be an issue for the Boost pointers. My
own reference counted pointers were invasive, and required the
pointed to object to derive from a specific base class. Which,
of course, void doesn't.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Dec 4 '07 #10

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

4 posts views Thread by Philippe Guglielmetti | last post: by
6 posts views Thread by Ryan Mitchley | last post: by
2 posts views Thread by Dennis Jones | last post: by
2 posts views Thread by krema2ren | last post: by
2 posts views Thread by adebaene | last post: by
5 posts views Thread by Jun | last post: by
4 posts views Thread by EnsGabe | last post: by
10 posts views Thread by tradevol | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.