Loading ...
Sorry, an error occurred while loading the content.

Re: [Boost-Users] Re: const shared_ptr<>

Expand Messages
  • Hossein Haeri
    Dear John, ... I can t understand! Can you please describe your idea more? Do you mean that calling a non-const member function for shared_ptr will result
    Message 1 of 13 , May 1, 2003
    • 0 Attachment
      Dear John,

      > I'd say you could call any of the 'const' member
      > functions (e.g.
      > operator*(), operator->(), get(),...,etc), but the
      > returned type is a
      > non-const pointer.
      >
      > Since operator*() is a const member function, it is
      > legal on a const
      > shared_ptr<T>. The '=', then, applies to the
      > non-const shared ptr
      > returned, not to the shared_ptr<T> object, itself.

      I can't understand! Can you please describe your idea
      more? Do you mean that calling a non-const member
      function for shared_ptr<T> will result in acting the
      desired operatio on a temporal mutable copy of the
      original const version?

      > Note also, that you're supposed to initialized
      > shared_ptr<T> with a
      > *dynamically* allocated T (use new), because it will
      > call 'delete' on
      > the ptr when the last reference disappears. So you
      > are wrong to
      > initialize it with the address of a stack variable.

      Thank you very much because of recalling that to me.
      But a subtle point here is that the asserion you made
      is not true for all types. If T is not a scaler type,
      it has some destructor, so I can call that destructor
      explicitely, before the compiler does it, and before
      the end of shared_ptr<T>. This way, there would be no
      problem had I initiialised the share_ptr<T> with an
      object of type T.

      Wishes,
      --Hossein


      __________________________________
      Do you Yahoo!?
      The New Yahoo! Search - Faster. Easier. Bingo.
      http://search.yahoo.com
    • Hossein Haeri
      Dear John, I have done a mistake in the answer to your following ... By the destructor of the object, I meant some mechanism for realeasing the contained
      Message 2 of 13 , May 1, 2003
      • 0 Attachment
        Dear John,

        I have done a mistake in the answer to your following
        assertion:

        > Note also, that you're supposed to initialized
        > shared_ptr<T> with a
        > *dynamically* allocated T (use new), because it will
        > call 'delete' on
        > the ptr when the last reference disappears. So you
        > are wrong to
        > initialize it with the address of a stack variable.

        By the destructor of the object, I meant some
        mechanism
        for "realeasing" the contained object whithin
        boost::shared_ptr<>. Silly! Not?

        So the true answer is not to forget to call the
        reset()
        member function for every shared_ptr<>, before the end
        of it's scope.

        Thanks,
        --Hossein



        __________________________________
        Do you Yahoo!?
        The New Yahoo! Search - Faster. Easier. Bingo.
        http://search.yahoo.com
      • Darin Adler
        ... No, that won t do any good. When you do a reset(), the shared_ptr relinquishes ownership of the thing it points to. If it s the sole owner, it will destroy
        Message 3 of 13 , May 1, 2003
        • 0 Attachment
          On Thursday, May 1, 2003, at 04:57 AM, Hossein Haeri wrote:

          > So the true answer is not to forget to call the reset() member
          > function for every shared_ptr<>, before the end of it's scope.

          No, that won't do any good. When you do a reset(), the shared_ptr
          relinquishes ownership of the thing it points to. If it's the sole
          owner, it will destroy the object. It's simply an error to put a
          pointer to a stack object inside a shared_ptr; you can't correct that
          error with a reset() call.

          -- Darin
        • John Harris
          ... that ... I agree with Darin. Shared_ptr is used for automatically deleting a heap object when the last reference to it (that is, the last copy of the
          Message 4 of 13 , May 1, 2003
          • 0 Attachment
            --- In Boost-Users@yahoogroups.com, Darin Adler <darin@b...> wrote:
            > On Thursday, May 1, 2003, at 04:57 AM, Hossein Haeri wrote:
            >
            > > So the true answer is not to forget to call the reset() member
            > > function for every shared_ptr<>, before the end of it's scope.
            >
            > No, that won't do any good. When you do a reset(), the shared_ptr
            > relinquishes ownership of the thing it points to. If it's the sole
            > owner, it will destroy the object. It's simply an error to put a
            > pointer to a stack object inside a shared_ptr; you can't correct
            that
            > error with a reset() call.
            >
            > -- Darin

            I agree with Darin. Shared_ptr is used for automatically deleting a
            heap object when the last reference to it (that is, the last copy of
            the shared_ptr managing it) goes out of scope. It keeps count as the
            shared_ptr is copied around through parameters and return values and
            is constructed and destroyed. The underlying count goes up on
            construction and down on destruction. When the count gets to
            zero, 'delete' is called on your object.

            It is used to prevent copies of an object from being made.

            Hossein, if you'll post a description of what you really want to do,
            then we might be able to suggest a better idiom for you to follow.

            jh
          • Hossein Haeri
            Dear John, ... You are too nice to me because of keeping track of my issues so much! But I don t have any seroius work to do on this latter topic, and your
            Message 5 of 13 , May 2, 2003
            • 0 Attachment
              Dear John,

              > Hossein, if you'll post a description of what you
              > really want to do,
              > then we might be able to suggest a better idiom for
              > you to follow.

              You are too nice to me because of keeping track of my
              issues so much! But I don't have any seroius work to
              do on this latter topic, and your previouse answers
              were enough for my application. The only point is that
              I was trying to purge my mistake. That's all!

              But if you want to know about the reason behind my
              first question, I'm going to define a new "holder"
              object (named so by Bjarne Stroustrup), that is
              described in an artocle, which I'm writting these
              days.
              I would be pleased if I can post a proposal for that
              object to Boost, but I don't know how. You will help
              me if you can tell me about the way.

              Thanks,
              --Hossein

              __________________________________
              Do you Yahoo!?
              The New Yahoo! Search - Faster. Easier. Bingo.
              http://search.yahoo.com
            Your message has been successfully submitted and would be delivered to recipients shortly.