Question

I’m following the Microsoft sample code given for “How to create a sink interface in a MFC-based COM client” in order to create an event sink in C++ (VC6). The event source is a .NET assembly that exposes it’s functionality via COM interop.

The thing that is giving me fits is the very last note of the sample:

Because CMySink was created on the heap, make sure you delete it to
avoid memory leaks.

A couple of things I’m noting:

• The auto-increment / decrement parameter of GetIDispatch and AfxConnectAdvise / AfxConnectUnadvise is set to FALSE, so I’m assuming the internal reference count for the sink remains unchanged throughout the exercise.
• The OnFinalRelease method is not shown in the exercise, so I’m assuming it is the default behavior of deleting the instance of the sink.

Keeping in mind that final note in the sample text, my clean-up code looks something like this:

//Get a pointer to sinks IUnknown, no AddRef.
LPUNKNOWN pUnkSink = m_pSink->GetIDispatch(FALSE);

//Terminate a connection between source and sink.
//m_pUnkSrc is IUnknown of server obtained by CoCreateInstance().
//m_dwCookie is a value obtained through AfxConnectionAdvise().
AfxConnectionUnadvise(m_pUnkSrc, IID_MYEVENT, pUnkSink, FALSE,
   m_dwCookie);
delete m_pUnkSink;

The code this sample is part of runs in a loop that involves creating the sink, wiring it up, waiting for a few events, then tearing it down and deleting it. What I am seeing is that, after a few rounds through the loop, OnFinalRelease is called out of the blue. Not only that, OnFinalRelease is being called on the instance of the sink for the current iteration of the loop (not some previous instance used by a prior iteration of the loop). The effect is that the current sink gets deleted out from under the current loop execution, and a bunch of null pointer errors result.

I tried removing the call to delete m_pUnkSink. The result is OnFinalRelease is never called. This leaves me with a memory leak, as all of those instances of the sink accumulate in the heap.

I think I could probably get away with reusing the same instance of the sink for each iteration of the loop, but I’m curious what the correct lifetime management is. Do I need to make an explicit choice between deleting the instance myself and overriding OnFinalRelease to do nothing vs. never deleting myself and always expecting OnFinalRelease to perform the delete? Is one preferred to the other?

Answer 1

The default implementation of OnFinalRelease is to delete the object. It would probably be best to subclass CCmdTarget to gain the message map and event hooks and make your own class which can stay in scope for all processing needed then only delete once at the end. You could add a callback or notification message to signal being done with everything to clean your object up.

You don’t want to be allocating and deleting from the heap in a loop for performance reasons if nothing else anyway.

Update:

If the default implementation is undesirable, as is the case often with MFC, then your best option is to override the virtual OnFinalRelease and have it do nothing instead of calling delete this; like it does in CCmdTarget. Then it’s entirely on you to delete your object and clean up after yourself. I’d make your sink class reference counted object or put it in a smart pointer of some kind like std::unique_ptr if you have C++0x support.