Re: Is this the Right way TO release COM interface ?

From:

DerTopper@web.de

Newsgroups:

microsoft.public.vc.language

Date:

Tue, 21 Apr 2009 07:05:45 -0700 (PDT)

Message-ID:

<ddbfc9c6-1f76-43d8-8447-077747dd300f@p11g2000yqe.googlegroups.com>

On 21 Apr., 12:19, Sachin <Sac...@discussions.microsoft.com> wrote:

Hi
recently i have modified my source code to make more robust in exception
workflow.
My concern is avoiding Memory leaks or dangling interfaces. So i hace
implemented RAII ( resource acquisition is Initialisation ) kind of technique
in most of functions. to give you equivalent example it goes like ...

void func( IMAPIfolder* f)
{
    IMAPIfolder * folder = f;
    IMAPITable *contents = NULL;

   folder->GetContentsTable(&contents);

    // This class will be responsible to release the content interface in
//its destructor
      CSmartFolderContent fcontent(contents);

   // now i want to make sure that whatever happens in subsequent
//processing when this function exits the content interface must be released
.

    try
  {

     // some processing
     // call another function
    // etc
  }

  // not all exception will be catched so i cant release content here
catch(my_exception e)
{

  }

}

is there any harm for assigning and releasing COM interfaces like this ?

except double releasing i think there is no harm in this type of strategy ..

I use the automatically generated .tlh headers that you get when you
#import type libraries (either *.tlb, or *.exe or *.dll files). Those
headers use the smart pointer template _com_ptr_t, and can provides a
lot of wrapping functionality: For example a COM function
HRESULT GetSomeDevice ([in] int ID, [retval] ISomeInterface** RetVal);
gets mapped to
ISomeInterfacePtr GetSomeDevice (int ID);
This saves you from having to write ugly code.

I'd strongly advise to use smart pointers throughout your application.
If it contains a single plain pointer, or any call to Release or
AddRef, you'll most probably end up with some leak (in that regard
Visual Basic is a better language from COM: you'll never ever see any
life-time related management code, everything happens behind the
scenes).

Regards,
Stuart