Thread: smart pointer release

  1. #1
    Registered User
    Join Date
    May 2006
    Posts
    1,579

    smart pointer release

    Hello everyone,


    About the release method implementation of smart pointer of COM, there are two approaches below, and approach 1 is preferred is recommended by Inside COM -- should be better.

    Anyone know why approach 1 is better than approach 2?

    (m_pI is interface pointer to a COM interface of type T, and it is a member variable of the COM smart pointer class)

    Approach 1:

    Code:
    void Release()
    {
        if (m_pI != NULL)
        {
            T* pOld = m_pI;
            m_pI = NULL;
            pOld->Release();
        }
    }
    Approach 2:

    Code:
    void Release()
    {
        if (m_pI != NULL)
        {
            m_pI -> Release();
            m_pI = NULL;
        }
    }

    thanks in advance,
    George

  2. #2
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    If it's a smart pointer, then what's the point in releasing anything at all? The smart pointer should do that for you; otherwise it's not a smart pointer.
    Unless I'm misunderstanding. The both code samples do the same thing, only the first leaves a pOld pointer dangling, which can be dangerous.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  3. #3
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Thanks Elysia,


    In this case, I am talking about how to implement a smart pointer. Especially, how to implement a smart pointer's release function.

    Have I made myself understood?

    Quote Originally Posted by Elysia View Post
    If it's a smart pointer, then what's the point in releasing anything at all? The smart pointer should do that for you; otherwise it's not a smart pointer.
    Unless I'm misunderstanding. The both code samples do the same thing, only the first leaves a pOld pointer dangling, which can be dangerous.

    regards,
    George

  4. #4
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Yes. However, I'd go for the second code. No need for the first.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  5. #5
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Thanks Elysia,


    I also agree with you. Even if it is original code for Inside COM book, let us just keep it there. :-)

    Quote Originally Posted by Elysia View Post
    Yes. However, I'd go for the second code. No need for the first.

    regards,
    George

  6. #6
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    The reason is probably a misguided attempt to provide some supposed thread safety. Won't work, though, because the things doesn't synchronize in any way.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  7. #7
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,318
    Approach 1 is used because of exception saftey afaik. Think what would happen if Release throwed.
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  8. #8
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    It's COM. It must not throw in the first place.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  9. #9
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,318
    I know, I use COM every day at work. Actually I think I've figured it out. It's to do with re-entrancy.

    Inside Release, the object's destructor is called if this was the last CComPtr to be holding this object. Now what if for some bizarre reason that object contained a CComPtr to itself, which is what we just called Release on?
    First Approach - no problem, during the destructor's call to Release (which is in turn inside the first call to Release) the pointer is already NULL.
    Second Approach - Boom! during the destructor's call to Release the refcount gets subtracted again and goes below zero.

    Anyway, for both reasons I've stated, Approach 1 is safer.
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  10. #10
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Thanks CornedBee,


    Do you mean there is no need to make synchronization in destructor? Why? Supposing two threads wants to destruct the same object instances at the same time?


    Quote Originally Posted by CornedBee View Post
    The reason is probably a misguided attempt to provide some supposed thread safety. Won't work, though, because the things doesn't synchronize in any way.
    Thanks iMalc!


    Your answer is great!

    Quote Originally Posted by iMalc View Post
    I know, I use COM every day at work. Actually I think I've figured it out. It's to do with re-entrancy.

    Inside Release, the object's destructor is called if this was the last CComPtr to be holding this object. Now what if for some bizarre reason that object contained a CComPtr to itself, which is what we just called Release on?
    First Approach - no problem, during the destructor's call to Release (which is in turn inside the first call to Release) the pointer is already NULL.
    Second Approach - Boom! during the destructor's call to Release the refcount gets subtracted again and goes below zero.

    Anyway, for both reasons I've stated, Approach 1 is safer.

    regards,
    George

  11. #11
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Quote Originally Posted by George2 View Post
    Do you mean there is no need to make synchronization in destructor? Why? Supposing two threads wants to destruct the same object instances at the same time?
    Umm no, CornedBee suggested it might be a (rather poor) way of doing thread synchronization, if I understood right.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  12. #12
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Thanks Elysia,


    My question is, is it possible that two threads are invoking destructor at the same time? If yes, surely we need some synchronization approach, maybe different from the code I posted above. :-)

    Quote Originally Posted by Elysia View Post
    Umm no, CornedBee suggested it might be a (rather poor) way of doing thread synchronization, if I understood right.

    regards,
    George

  13. #13
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    If two threads use the same variable then yes. But since it's a smart pointer, you've probably got a copy of it on another thread, which means it won't call the same destructor.
    However, things can still mess up since both can call their respective destructor at the same time. Thread safety is a messy thing. The best thing to do is synchronize access to constructor and destructor, as well as any public access method (and you should do manual synchronize when using the object too).
    Otherwise you could run into nasty racing issues.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  14. #14
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,318
    Quote Originally Posted by Elysia View Post
    If two threads use the same variable then yes.
    No it is not a problem!

    The fundamentals of COM require that incrementing and decrementing the reference count be threadsafe, assuming you've correctly uses CComMultiThreadModel like you're supposed to if your COM object can live in a multi-threaded apartment. In this case it then uses InterlockedDecrement, so only one thread can ever see the refcount be decremented to zero. Furthurmore it would be a bug if the refcount were ever one and multiple threads called Release, though that still would not cause more than one thread to try and delete the object.
    Thus only one of the threads can ever call delete on the object.

    As I said, I use COM every day at work, and I don't think Elysia has used COM much, if at all.
    You can certainly trust Elysia for a quick answer, but often not for a correct one.
    Last edited by iMalc; 02-11-2008 at 02:35 AM.
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  15. #15
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Quote Originally Posted by iMalc View Post
    No it is not a problem!
    Of course it's a problem. It all depends on the implementation of the smart pointer class. Mayhap COM itself may be thread safe, but no the class itself.

    As I said, I use COM every day at work, and I don't think Elysia has used COM much, if at all.
    You can certainly trust Elysia for a quick answer, but often not for a correct one.
    No always correct, no, but no one can be.
    I have used COM somewhat, but never really implemented it nor used it in a threaded environment, so that is beyond me.
    I don't know the depths of COM, either. I know how to use it, AddRef, Release, QueryInterface, CoCreateInstance, etc. And frankly, COM annoys me, so I avoid it. My knowledge on COM itself isn't perhaps what it should be.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. sorting the matrix question..
    By transgalactic2 in forum C Programming
    Replies: 47
    Last Post: 12-22-2008, 03:17 PM
  2. Direct3D problem
    By cboard_member in forum Game Programming
    Replies: 10
    Last Post: 04-09-2006, 03:36 AM
  3. scope of a pointer?
    By Syneris in forum C++ Programming
    Replies: 6
    Last Post: 12-29-2005, 09:40 PM
  4. pointers
    By InvariantLoop in forum C Programming
    Replies: 13
    Last Post: 02-04-2005, 09:32 AM
  5. Struct *** initialization
    By Saravanan in forum C Programming
    Replies: 20
    Last Post: 10-09-2003, 12:04 PM