Board index » Visual Studio » CComQIPtr doubt

Visual Studio156
can i reuse CComQIPtr? i mean i want to release this CComQIPtr for

reuse .this is a member variable

in certain situation i have to maintain this variable, some times

has to change.



what i am doing is creating local CComQIPtr and assigning in to

member CComQIPtr variable.

is this feasible?



one more doubt any problem CComQIPtr in different thread?because

releasing time it is crashing..

thanks for advance..


-

<keralafood@gmail.com>ha scritto nel messaggio

I'm not sure I have understood your question well...



However, CComQIPtr and CComPtr have been designed to hide the complexity of

COM rules about AddRef/Release for COM interfaces.

i.e. CComPtr/CComQIPtr perform automatic reference counting for you (for

example, they call Release on the interface attached to them, when the

smart-pointer variable goes out of scope).



So, I think it's safe to use them as a class data member, if that was the

question...



Again, this part of the question is not very clear to me.

Maybe in your code you may want to protect access to a CComQIPtr instance

using a synchronization primitive like CRITICAL_SECTION?



Giovanni





-

sorry for my bad English..my doubt is this,is there any trick to

release CComQIPtr manually?

if i want to release some interface ,and re create, how i do with

CComQIPtr ?what i did was ,using temporary variable and assigning into

my original member variable.. but automatic release crashing(after

class destructor)..i believe i did some thing wrong.

regarding multi thread problem ,i am creating CComQIPtr in one therad

and try to use in different thread,is giving error ,"this object

cerated by different thread "..so i force to re create object again.

-

<keralafood@gmail.com>ha scritto nel messaggio

No problem for your English; I think mine could be even worse :)



CComQIPtr derives from CComPtrBase, and so it inherits the Release() method.

You can call it.



BTW: It seems to me that I have replied a similar question in another

newsgroup... please don't multipost.

Thanks.



Giovanni







-

keralafood@gmail.com wrote:

Just call Detach on it:



CComQIPtr SmartPointer;

SmartPointer.CreateInstance (SomeClassID);

// SmartPointer is now attached to the newly created object.



SmartPointer.Detach ();

// SmartPointer is pointing nowhere, but the newly created object still

// has a reference count of one.



If I understand your previous question right, you are not sure whether you can

use the same smart pointer for two different objects. You can do the following:



// Create first object.

IUnknown* Pointer1;

::CoCreateInstance (SomeClassID, NULL, (void**) &Pointer1);



CComQIPtr SmartPointer (Pointer1);

// SmartPointer points now to the same object as Pointer1. CComQIPtr has

// taken care to increase the reference count of the object to two.



// Create second object.

IUnknown* Pointer2;

::CoCreateInstance (SomeClassID, NULL, (void**) &Pointer2);



SmartPointer = Pointer2;

// SmartPointer is pointing to the second object. It has _decreased_

// the reference count on the first object by one and _increased_ the

// reference count of the second object by one.



Best of all, don't use any plain pointers throughout your whole application.

Plain pointers are almost impossible to maintain, so you might end up working

with pointers that point to objects that have already been destroyed.



One thing that might have happened to you might be the following: If you have a

smart pointer as member of the application object, you have to ensure that the

smart pointer is set to NULL before your application calls CoUninitialize (which

is often done in the destructor of the class object). Else you might encounter

the problem that the destructor of the smart pointers is called _after_ the call

to CoUninitalize has been made.



This sounds like you should read about Marshaling and Apartments. If you want to

use a pointer created in the main thread inside a worker thread, you'll have to

use some marshaling code (like CoMarshalInterfaceInStream). Remember that you

have to call CoInitialize in your worker threads as well.



Regards,

Stuart

-

Thanks,a lot..got valuable information...

-