boost::shared_ptr - NULL

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Christopher

    boost::shared_ptr - NULL

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

  • David Harmon

    #2
    Re: boost::shared_p tr - NULL

    On Sat, 1 Dec 2007 11:36:51 -0800 (PST) in comp.lang.c++,
    Christopher <cpisz@austin.r r.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_p tr<sometype>()) {

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

    Comment

    • James Kanze

      #3
      Re: boost::shared_p tr - NULL

      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.r r.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_p tr<sometype>()) {
      How about:
      if ( retvalue == NULL ) { ... }

      I've not looked at boost::shared_p tr 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:james.kan ze@gmail.com
      Conseils en informatique orientée objet/
      Beratung in objektorientier ter Datenverarbeitu ng
      9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

      Comment

      • Greg Herlihy

        #4
        Re: boost::shared_p tr - NULL

        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.r r.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_p tr<sometype>()) {
        How about the more succinct:

        if (not retval) {

        or, alternately:

        if (retval == false) {

        Greg

        Comment

        • Michael DOUBEZ

          #5
          Re: boost::shared_p tr - NULL

          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.r r.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_p tr<sometype>()) {
          >
          How about:
          if ( retvalue == NULL ) { ... }
          >
          I've not looked at boost::shared_p tr in this regard, but all of
          the intelligent pointers I've written accept it.
          Boost share_ptr doesn't provide a operator==(smar t_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_cou nt()?smart.ptr: NULL) == ptr' when the intended operations
          in the case ptr=NULL would have been '(use_count()== 0) ||
          (smart.ptr==NUL L)'.
          >
          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

          Comment

          • James Kanze

            #6
            Re: boost::shared_p tr - NULL

            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.r r.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_p tr<sometype>()) {
            How about:
            if ( retvalue == NULL ) { ... }
            I've not looked at boost::shared_p tr in this regard, but all of
            the intelligent pointers I've written accept it.
            Boost share_ptr doesn't provide a operator==(smar t_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_cou nt()?smart.ptr: NULL) == ptr' when the intended operations
            in the case ptr=NULL would have been '(use_count()== 0) ||
            (smart.ptr==NUL L)'.
            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:james.kan ze@gmail.com
            Conseils en informatique orientée objet/
            Beratung in objektorientier ter Datenverarbeitu ng
            9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

            Comment

            • Michael DOUBEZ

              #7
              Re: boost::shared_p tr - NULL

              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++,
              >>>Christophe r <cp...@austin.r r.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_p tr<sometype>()) {
              >>How about:
              >> if ( retvalue == NULL ) { ... }
              >>I've not looked at boost::shared_p tr in this regard, but all of
              >>the intelligent pointers I've written accept it.
              >
              >Boost share_ptr doesn't provide a operator==(smar t_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

              Comment

              • Abhishek Padmanabh

                #8
                Re: boost::shared_p tr - NULL

                On Dec 3, 2:39 pm, James Kanze <james.ka...@gm ail.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?

                Comment

                • Michael DOUBEZ

                  #9
                  Re: boost::shared_p tr - NULL

                  Abhishek Padmanabh a écrit :
                  On Dec 3, 2:39 pm, James Kanze <james.ka...@gm ail.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<Foob ar;
                  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

                  Comment

                  • James Kanze

                    #10
                    Re: boost::shared_p tr - NULL

                    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.r r.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_p tr<sometype>()) {
                    >How about:
                    > if ( retvalue == NULL ) { ... }
                    >I've not looked at boost::shared_p tr in this regard, but all of
                    >the intelligent pointers I've written accept it.
                    Boost share_ptr doesn't provide a operator==(smar t_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:james.kan ze@gmail.com
                    Conseils en informatique orientée objet/
                    Beratung in objektorientier ter Datenverarbeitu ng
                    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

                    Comment

                    Working...