Re: CoUninitialize() and CComPtr<> object lifetimes
- From: "Igor Tandetnik" <itandetnik@xxxxxxxx>
- Date: Sat, 9 Jul 2005 21:30:24 -0400
"Riley DeWiley" <riley.dewiley@xxxxxxxxx> wrote in message
news:P4qdnS3RU5Ct8k3fRVn-hQ@xxxxxxxxxx
> I have tracked down a bug involving object lifetimes to a quirk in
> CComPtr<> that is related to CoInitialize() and CoUninitialize(). It
> seems that the destructor for my CComPtr<> is not being called until
> CoUnitialize() is called, even though the variable itself has gone
> out of scope. It does not help that CoInitialize() is being called
> somewhere in the app framework.
> Here is the issue, it appears in an OnInitDialog() fxn for a modal
> dialog:
> LRESULT OID( ... blah ...)
> {
> //CoInitialize() has already been called ...
> CComPtr<IMyOb> pOb = 0; //local declaration of ccomptr, OK
> HRESULT hr = CoCreateInstance( ..., inproc|local server,
> IID_IMyOb, &pOb ...);
> ..error check on hr ...
> pOb->foo();
> return SOMETHING;
> }
>
> With the code above, I would expect that the dtor for _Module would
> fire right after the return() statement
You would be wrong. _Module is a global variable, its constructor is
called when the DLL is loaded, and its destructor - when the DLL is
unloaded. COM does not unload the DLL as soon as the last object is
released. Left to its own devices, COM would never unload a DLL it
loaded until CoUninitialize. But see CoFreeUnusedLibraries
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925
.
- References:
- CoUninitialize() and CComPtr<> object lifetimes
- From: Riley DeWiley
- CoUninitialize() and CComPtr<> object lifetimes
- Prev by Date: CoUninitialize() and CComPtr<> object lifetimes
- Next by Date: Re: COM replacement for BYTE* type?
- Previous by thread: CoUninitialize() and CComPtr<> object lifetimes
- Index(es):
Relevant Pages
|
