Re: coding style
"Alex Blekhman" <tkfx.REMOVE@yahoo.com> ha scritto nel messaggio
news:uSZWmkvlIHA.3512@TK2MSFTNGP03.phx.gbl...
There is not enough information to say conclusively whether this code is
ugly or not. Although generally macros are evil, still there are situatons
where macros may be helpful.
I do agree.
One should use destructors to clean resources
Yes, in general RAII can help in building more quality code.
And I agree we should use RAII when possible.
However, RAII (and related smart pointers) may also have their fine points
and subtle aspects, e.g. in this code sample:
<pseudo-code>
some function or method
{
CoInitialize...
ComSmartPointer sp1;
ComSmartPointer sp2;
...
ComSmartPointer spN;
...
use COM objects via their associated smart pointers
...
... Assume that smart pointer destructors call Release()
CoUninitialize();
}
</pseudo-code>
The above code is wrong, because I believe that the smart pointer
destructors are called just before exiting the code block, so *first*
CoUninitialize is called, *then* the smart pointer destructors are called.
And that is not correct (because I think that CoUninitialize must be called
*after* all COM interfaces are Release'd).
This is a subtle thing.
*Explicit* Release() with a 'goto cleanup' statement (like some MSDN and
other SDK documentations do) would have made the code flow more clear, and
avoid the above bug.
<pseudo-code>
... if (FAILED(hr) )
goto cleanup;
...
.... if (FAILED(hr))
goto cleanup;
...
cleanup:
// Explicitly call Release here
...
</pseudo-code>
And IMHO a preprocessor macro like CHECK_HR (that checks if current HRESULT
is a failure code and jumps to 'cleanup' label accordingly) would be good in
that scenario, too.
Of course, there are workarounds for the aforementioned bug, too, e.g.
enclose the smart pointers into a { ... } block, and put
CoInitialize/CoUninitialize out of that block:
<pseudo-code>
{
CoInitialize...
{
... smart pointers defintition and usage...
}
CoUninitialize();
}
</pseudo-code>
Giovanni