Thanks for your comprehensive reply. As you may see my follow up crossed
Say I will be manipulating many images throughout the life of my program.
each object. But is that necessary? Is that for demonstration purposes or is
Regarding headers. How much overhead would adding ATL add?
As I understood it, you must release every resource obtained through
Queryinterface.
Would someone indicate why the pBasicBitmapOps->Release(); in the code
snippet below returns S_FALSE?
(the other Releases() return S_OK).
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.)
if (SUCCEEDED(pBitmapImage->QueryInterface(IID_IBasicBitmapOps,
(void**)&pBasicBitmapOps)))
{
hr=pBasicBitmapOps->Release();
}
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.