boost::shared_ptr - NULL

Discussion in 'C++' started by Christopher, Dec 1, 2007.

  1. Christopher

    Christopher Guest

    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?
     
    Christopher, Dec 1, 2007
    #1
    1. Advertising

  2. * Christopher:
    > 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?


    Return boost::shared_ptr<sometype>().

    Hm.

    I'm amazed about some of the questions here. Please read the manual
    before posting. Or at least, /glance/ at it.


    Cheers, & hth.,

    - Alf

    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
     
    Alf P. Steinbach, Dec 1, 2007
    #2
    1. Advertising

  3. Christopher

    Christopher Guest

    On Dec 1, 1:29 pm, "Alf P. Steinbach" <> wrote:
    > * Christopher:
    >
    > > 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?

    >
    > Return boost::shared_ptr<sometype>().
    >
    > Hm.
    >
    > I'm amazed about some of the questions here. Please read the manual
    > before posting. Or at least, /glance/ at it.
    >
    > Cheers, & hth.,
    >
    > - Alf
    >
    > --
    > A: Because it messes up the order in which people normally read text.
    > Q: Why is it such a bad thing?
    > A: Top-posting.
    > Q: What is the most annoying thing on usenet and in e-mail?


    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, and it
    says that behavior is undefined if you dereference it while the
    internal pointer is NULL.

    I've got a method in a class that allocates an object of a different
    type and it has been deemed "unsafe" to return a raw pointer to it.
    However, if the allocation or preliminary steps before allocation
    fail, I want to return NULL.
     
    Christopher, Dec 1, 2007
    #3
  4. * Christopher:
    > On Dec 1, 1:29 pm, "Alf P. Steinbach" <> wrote:
    >> * Christopher:
    >>
    >>> 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?

    >> Return boost::shared_ptr<sometype>().
    >>
    >> Hm.
    >>
    >> I'm amazed about some of the questions here. Please read the manual
    >> before posting. Or at least, /glance/ at it.

    >
    > Are you referring to the boost manual?
    > http://www.boost.org/libs/smart_ptr/scoped_ptr.htm


    Looks like it, yes.

    Btw., please don't quote signatures (corrected).


    > 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, and it
    > says that behavior is undefined if you dereference it while the
    > internal pointer is NULL.
    >
    > I've got a method in a class that allocates an object of a different
    > type and it has been deemed "unsafe" to return a raw pointer to it.
    > However, if the allocation or preliminary steps before allocation
    > fail, I want to return NULL.


    Perhaps take a second glance at the docs.


    Cheers, & hth.,

    - Alf

    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
     
    Alf P. Steinbach, Dec 1, 2007
    #4
  5. Christopher

    David Harmon Guest

    On Sat, 1 Dec 2007 11:36:51 -0800 (PST) in comp.lang.c++,
    Christopher <> wrote,
    >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.
     
    David Harmon, Dec 1, 2007
    #5
  6. Christopher

    James Kanze Guest

    On Dec 1, 9:19 pm, David Harmon <> wrote:
    > On Sat, 1 Dec 2007 11:36:51 -0800 (PST) in comp.lang.c++,
    > Christopher <> wrote,


    > >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:
    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
     
    James Kanze, Dec 2, 2007
    #6
  7. "James Kanze" <> wrote in message
    news:...
    On Dec 1, 9:19 pm, David Harmon <> wrote:
    > On Sat, 1 Dec 2007 11:36:51 -0800 (PST) in comp.lang.c++,
    > Christopher <> wrote,


    > >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 ) ...


    Yes, I tryed if( retval == NULL ) and it would not compile. However, the
    get method does work. I've got it now, I just don't like it much over using
    raw pointers. I've always been of the opinion that, if I make a method that
    allocates something, I just document it and count on the caller to know what
    to do. I don't think I like trying to idiot proof things, because I am just
    introducing more nuiances. If I've never used these smart pointers and don't
    know how, I suspect the callers of my methods won't either. I really doubt
    they will take the time to learn how the shared_ptr works, what can and
    can't be done with it etc., no matter how much I do or don't. Ah well.
     
    Christopher Pisz, Dec 3, 2007
    #7
  8. Christopher

    Greg Herlihy Guest

    On Dec 1, 12:19 pm, David Harmon <> wrote:
    > On Sat, 1 Dec 2007 11:36:51 -0800 (PST) in comp.lang.c++,
    > Christopher <> wrote,
    >
    > >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
     
    Greg Herlihy, Dec 3, 2007
    #8
  9. James Kanze a écrit :
    > On Dec 1, 9:19 pm, David Harmon <> wrote:
    >> On Sat, 1 Dec 2007 11:36:51 -0800 (PST) in comp.lang.c++,
    >> Christopher <> wrote,

    >
    >>> 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
     
    Michael DOUBEZ, Dec 3, 2007
    #9
  10. Christopher

    James Kanze Guest

    On Dec 3, 6:36 am, Michael DOUBEZ <> wrote:
    > James Kanze a écrit :
    > > On Dec 1, 9:19 pm, David Harmon <> wrote:
    > >> On Sat, 1 Dec 2007 11:36:51 -0800 (PST) in comp.lang.c++,
    > >> Christopher <> wrote,


    > >>> 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:
    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
     
    James Kanze, Dec 3, 2007
    #10
  11. James Kanze a écrit :
    > On Dec 3, 6:36 am, Michael DOUBEZ <> wrote:
    >> James Kanze a écrit :
    >>> On Dec 1, 9:19 pm, David Harmon <> wrote:
    >>>> On Sat, 1 Dec 2007 11:36:51 -0800 (PST) in comp.lang.c++,
    >>>> Christopher <> wrote,
    >>>>> 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
     
    Michael DOUBEZ, Dec 3, 2007
    #11
  12. On Dec 3, 2:39 pm, James Kanze <> wrote:
    > On Dec 3, 6:36 am, Michael DOUBEZ <> wrote:
    > > 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?
     
    Abhishek Padmanabh, Dec 3, 2007
    #12
  13. Abhishek Padmanabh a écrit :
    > On Dec 3, 2:39 pm, James Kanze <> wrote:
    >> On Dec 3, 6:36 am, Michael DOUBEZ <> wrote:
    >>> 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<Foo> bar;
    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
     
    Michael DOUBEZ, Dec 3, 2007
    #13
  14. Christopher

    James Kanze Guest

    On Dec 3, 2:20 pm, Michael DOUBEZ <> wrote:
    > James Kanze a écrit :


    > > On Dec 3, 6:36 am, Michael DOUBEZ <> wrote:
    > >> James Kanze a écrit :
    > >>> On Dec 1, 9:19 pm, David Harmon <> wrote:
    > >>>> On Sat, 1 Dec 2007 11:36:51 -0800 (PST) in comp.lang.c++,
    > >>>> Christopher <> wrote,
    > >>>>> 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:
    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
     
    James Kanze, Dec 4, 2007
    #14
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Philippe Guglielmetti
    Replies:
    4
    Views:
    918
    tom_usenet
    Oct 9, 2003
  2. Raf256
    Replies:
    1
    Views:
    2,254
    Howard Hinnant
    Apr 19, 2005
  3. Toby Bradshaw
    Replies:
    6
    Views:
    1,799
    Kai-Uwe Bux
    Jun 2, 2006
  4. Colin Caughie
    Replies:
    1
    Views:
    751
    Shooting
    Aug 29, 2006
  5. Replies:
    10
    Views:
    3,854
    James Kanze
    Aug 6, 2008
Loading...

Share This Page