这个智能指针使用有什么问题？

Question

I recently saw a PowerPoint on Smart Pointers and their pitfalls, which had this slide (with virtually no commentary or explanation:

In context: specifically the _com_ptr_t , Smart Pointer for COM-interfaces that handles AddRef/Release, as created by a _COM_SMARTPTR_TYPEDEF macro.*

---

Wrong:

 IObjectPtr spObj; for (int i(0); i<MAX; i++) { //passed as actual , no release of previous ptr value spOtherObj->get_Obj(&spObj); } 

---

The next slide claims that it is okay if you put the spObj within the scope of the loop:

---

Right:

 for (int i(0); i<MAX; i++) { IObjectPtr spObj; //passed as actual , no release of previous ptr value spOtherObj->get_Obj(&spObj); } 

---

I've studied this, and still cannot figure out what they're talking about.
What is the problem with the first one that is solved by the second one??

---

I'm guessing that, in fuller context, the right/wrong code would look like:
although I could be wrong in my assumptions

 _COM_SMARTPTR_TYPEDEF(ICalendar, __uuidof(ICalendar)) void get_Calendar(ICalendarPtr* pCalendar) { *pCalendar.CreateInstance(__uuidof(Calendar)); } void WrongMethod(void) { ICalendarPtr spCalendar; for (int i(0); i<MAX; i++) { //passed as actual , no release of previous ptr value get_Calendar(&spCalendar); } } 

Answer 1

This most likely refers to ATL::CComPtr and not _com_ptr_t .

The problem is that CComPtr::operator& returns the address of the wrapped pointer but doesn't release it, therefore leaking the objects if it is declared out of the loop, assuming that the wrapped interface is not NULL.

The implementation acknowledges this fact, this is copied straight from ATL headers, including comments:

//The assert on operator& usually indicates a bug.  If this is really
//what is needed, however, take the address of the p member explicitly.
T** operator&() throw()
{
    ATLASSERT(p==NULL);
    return &p;
}

_com_ptr_t fixes this problem, and is more convenient to use in general, so it should be preferred were applicable.

Answer 2

These are ATL::CComPtr smart pointers (which are marginally smart, btw).

The operator & for that object type returns the address of the raw interface pointer within. Therefore the first loop is literally no better than doing this:

IObject* pObj = NULL;
for (int i(0); i<MAX; i++)
{
    spOtherObj->get_Obj(&pObj);
}

With each iteration, the prior iteration's interface is never released. It is simply lost, leaked and the reference count on the underlying coclass will be artificially latched up.

By moving the smart pointer to the inside of the loop, you're now allowing the destructor of the smart-pointer object to clean up each interface acquired, firing ->Release() , before the next iteration. That code, expanded, is effectively this:

for (int i(0); i<MAX; i++)
{
    IObject* pObj = NULL;
    spOtherObj->get_Obj(&pObj);
    if (pObj) pObj->Release();
}