Re: COM, returned handles, and memory management
- From: "Riley DeWiley" <riley.dewiley@xxxxxxxxx>
- Date: Fri, 16 Sep 2005 12:46:53 -0700
On second thought, how do I pass "an object" across a COM interface?
The cast into / out of unsigned is just a kludge ...
RDeW
"Alexander Nickolov" <agnickolov@xxxxxxxx> wrote in message
news:ef6gdXuuFHA.3932@xxxxxxxxxxxxxxxxxxxxxxx
> I'm surprised nobody yet mentioned that thus is a bad design.
> Without knowing your objective, here's a simple approach
> that may be better: return an object instead of an opaque
> handle (e.g. an interface pointer). You can have a method
> on that object to return you the wrapped handle, but you
> have explicit lifetime management authority by holding the
> object alive. Alternatively, the original object can serve that
> purpose, though that may not fit with the rest of your design.
> BTW, by using a lifetime managemt object you get rid of the
> explicit CloseFoo method as it's not needed anymore.
>
> --
> =====================================
> Alexander Nickolov
> Microsoft MVP [VC], MCSD
> email: agnickolov@xxxxxxxx
> MVP VC FAQ: http://www.mvps.org/vcfaq
> =====================================
>
> "Riley DeWiley" <riley.dewiley@xxxxxxxxx> wrote in message
> news:66Odna3lbpr5YLTenZ2dnUVZ_tGdnZ2d@xxxxxxxxxxxxx
>>I have a COM DLL that is allocating memory and passing back an opaque
>>handle, like this:
>>
>> //allocates memory for new object
>> HRESULT CMyOb::OpenFoo(unsigned * hFoo)
>> {
>> Foo * pFoo = new Foo;
>> *hFoo = (unsigned)pFoo;
>> return S_OK;
>> }
>>
>>
>> //deletes object opened above
>> HRESULT CMyOb::CloseFoo(unsigned hFoo)
>> {
>> if(hFoo)
>> {
>> Foo * pFoo = (Foo *)hFoo;
>> delete pFoo;
>> return S_OK;
>> }
>> else
>> return E_INVALIDARG;
>> }
>>
>> Ignoring for now the obvious issues with the casts, I am noticing that
>> when the client uses it like this:
>>
>> HFOO hFoo = 0;
>> {
>> CComPtr pFoo<IFoo> pFoo;
>> CoCreateInstance(CLSID_FooHousing, CLSCTX_INPROC, etc., (void
>> **)&pFoo);
>> pFoo->OpenFoo(&hFoo);
>> //force pFoo out of scope, decrementing refcount to zero and unloading
>> DLL
>> }
>>
>>
>> {
>> //new CComPtr object in new scope, using old handle
>> CComPtr pFoo<IFoo> pAnotherFoo;
>> CoCreateInstance(CLSID_FooHousing, CLSCTX_INPROC, etc., (void
>> **)&pAnotherFoo);
>> pAnotherFoo->CloseFoo(hFoo); //whammo! A.V. on delete
>> }
>>
>> I get access violations when I hit the delete in CloseFoo(). The Foo
>> object pointed to is landfill. The client has not done anything with the
>> pointer in the meantime. It seems the DLL has unloaded between the two
>> calls and my memory has "gone away", causing the A.V.
>>
>> I want these pointers (handles) to persist. Two questions:
>> 1 - Am I correct in understanding the problem?
>>
>> 2 - What is a workaround, besides either (a) persisting the DLL by
>> holding a pointer to the interface, or (b) having the client own all the
>> memory? Is there a function I can call that will "hold" the memory if the
>> client unloads?
>>
>> RDeW
>>
>>
>>
>>
>>
>
>
.
- Follow-Ups:
- Re: COM, returned handles, and memory management
- From: Alexander Nickolov
- Re: COM, returned handles, and memory management
- From: Brian Muth
- Re: COM, returned handles, and memory management
- From: Igor Tandetnik
- Re: COM, returned handles, and memory management
- Prev by Date: Re: COM, returned handles, and memory management
- Next by Date: Re: COM, returned handles, and memory management
- Previous by thread: Re: COM, returned handles, and memory management
- Next by thread: Re: COM, returned handles, and memory management
- Index(es):
Relevant Pages
|
