Re: Queryinterface then Release fails

"Fred" <not@here.com> ha scritto nel messaggio
news:Ko-dnZKGgvATpa_aRVnytAA@pipex.net...


It's fine to ask here.
However, you may find the ATL group:

  microsoft.public.vc.atl

to be very interesting, too


Release is a method of IUnknown interface. IUnknown is the base interface
for all COM objects. Every COM object must implement at least the IUnknown
interface. IUnknown has three methods: QueryInterface, AddRef and Release.
So, because every COM interface is derived from IUnknown, you can call
QueryInterface, AddRef and Release on every COM interface.

Note that the prototype of Release is as follow:

"IUnknown::Release"
http://msdn2.microsoft.com/en-us/library/ms682317.aspx

 ULONG Release(void);

It is *not* "HRESULT Release(void)".
So, you must not interpret the return value of Release as a flag indicating
success or error (like S_OK, E_FAIL, etc. these are values valid only for
variables of type HRESULT.)

Release just returns the resulting value of the reference count of the
object. This reference count value returned by Release is used for
diagnostic/testing purposes only... you can just ignore it.
(Instead, you must check every HRESULT returned value, e.g. from
QueryInterface, or other interfaces methods.)


The above code is wrong.
IUnknown::Release does not return HRESULT.
Just call Release, like this:

<code>

  // (Decreases object reference count;
  // when ref count becomes 0,
  // the object destroys itself.)
  pBasicBitmapOps->Release();

  // Avoid danging references
  pBasicBitmapOps = NULL;

</code>

Or better, use an ATL smart pointer template class, like CComPtr or
CComQIPtr.
These offer automatic management for AddRef and Release, and you don't have
to pay attention to details like clearing pointer to NULL, to avoid dangling
references. So, for example, when the smart pointer instance created on the
stack goes out of scope, Release is automatically called by the smart
pointer.
These smart pointers help you write less code, less boilerplate, and more
high-quality and more robust code. You can concentrate on the main
algorithm, and don't pay attention to several details, and lose focus.

e.g.

CComPtr< IImageFactory > spImageFactory;

// When you create with CoCreateInstance...
hr = spImageFactory.CoCreateInstance( CLSID_ImagingFactory );

(Release automatically called when you exit the function. [*] )

See, for example, the CComPtr documentation on MSDN:

"CComPtr Class"
http://msdn2.microsoft.com/en-us/library/ezzw7k98(VS.80).aspx

Giovanni

[*] Note that, if you call CoInitialize and CoUninitialize in the same scope
of the smart pointer, then in this particular case you have to force a
Relase() call before calling CoUninitialize.

e.g.

  // #1
  {
    CoInitialize...

    CComPtr< ISomething > spSomething;

    ...
    use spSomething
    ...

    // Call .Release() before CoUninitialize
    spSomething.Release();
    CoUninitialize...
  }

  // #2 - If CoInitialize/CoUninitialize are called in an higher context:
  {
    CComPtr< ISomething > spSomething;

    ...
    use spSomething
    ...

    // Don't need to call Release
    // spSomething.Release();
  }

This is beacuse in case #1 the destructor of the smart pointer would be
called after CoUninitialized, and so COM is already shut down, and then
IUnknown::Release is called by the smart pointer destructor when COM is
uninitialized, and strange bad things can happen.
But, in general, I would call CoInitialize and CoUninitialize in a more
higher context (case #2), like WinMain or _tmain(), etc. not in the same
scope of the COM smart pointers.