Hi,

I've done some work with CComPtr and some thoughts, regarding when they are pointless to use and when AddRef is NOT called, troubles me. Maybe I've got it all wrong, maybe I've missed something really basic, so please share your wisdom with me!


"Pointless" or not?
=============

As far as I understand, the main idea of using CComPtr is to get an automatic reference counter. This works great in many situations, e.g. when you use it's constructor / assign operator to assign it an interface pointer or call its CoCreateInstance() method.

But, consider this:

ITest* pITest = NULL;
GetITest(&pITest);

GetITest() will as is common in such functions (that receives a pointer to an interface pointer), provide an interface pointer to an ITest object and call AddRef() on the object before returning. For instance, as IConnectionPointContainer::FindConnectionPoint() does.

So, when I'm done using pITest, I have to call pITest->Release().

Now, if I would use a CComPtr instead, it would look like something like this:

CComPtr<ITest> pITest;
GetITest(&pITest);

The "problem" is that when I'm done using pITest I cannot depend on the destructor in CComPtr to call Release(). I can't do this because CComPtr doesn't have a clue that AddRef was called by GetITest(). Instead I have to manually call pITest.Release() before it goes out of scope. So, for this situation I find it not only pointless but even dumb to use a CComPtr instead of a simple interface pointer, as the CComPtr gives you a false sense of safety.

It would have been very neat though if it would be possible to inform the CComPtr class that AddRef has already been called, so it would call Release() in the destructor. Calling AddRef on the CComPtr is of course not a solution.
But is there a trick for this!?