   Do I need Addref()?
  Hi,Im writing a camera class which has this member:PDIRECT3DDEVICE9 device;I intialize the device pointer in the ctor:ICamera::ICamera(PDIRECT3DDEVICE9 device) {this->device = device;My question is: Do I need a call of AddRef() of the device and a release() in the destructor of ICamera or is ok if I just have this simple assignment?   
  You should, otherwise the interface might vanish from underneath you.Using CComPtr<T> would make it much easier.   ;  Could you please explain what you mean with "vanish"? Right now I dont see a problem, even if I have 1000 pointers on the one device. I mean if i just call Release() once if the application terminates, then everything should be fine. Are there any potential errors which I dont see?   ;Quote:Original post by schupfCould you please explain what you mean with "vanish"? Right now I dont see a problem, even if I have 1000 pointers on the one device. I mean if i just call Release() once if the application terminates, then everything should be fine. Are there any potential errors which I dont see?But say you have 1000 pointers floating around held by 1000 different objects.  One object gets destroyed, this object happens to be the one responsible for calling release().  Then the other 999 objects are holding a pointer to a device that has already been destroyed.But which "owner" of the device should be responsible for calling release?If you add ref with each object that owns a pointer to the device, then you can call release with each object and know for certain that the device will not be destroyed until the last owner of the device calls release.Or pass around CComPtrs of the interface as mentioned above.  This willl automatically addref and releas4e when the pointer is obtained and when the CComPtr is destroyed.;  Interfaces are reference counted; you're supposed to add a reference to the interface if you intend to keep it around for any length of time. If you don't add a reference, the interface doesn't know you're referencing it, and if Release() is called and decrements the reference count to zero, the interface will go away and the next time you try to access it -- assuming its still around -- blam, you're dead.Yes, in practice you can probably get away with not doing every time you're supposed to, but there are still cases when you will get bitten by not doing it (especially when/if you move to D3D10, which does not add references to interfaces for you) and it's still bad practice.You can usually get away with never deleting any memory you allocate with new, either, relying on the OS to reclaim it when the process exits. But that doesn't make it good programming practice.If you use CComPtr<T> for your COM interfaces, you can effectively pass the interfaces around without worry, as CComPtr<T> is a COM-specific smart pointer that uses RAII to manipulate the reference count of the interface safely.   ;  Ok this makes sense.In the moment I have an architecture like this:All the objects with pointers to the device dont call AddRef() or Release. Only if the application is closed I call an exit() function with calls Release() (the only Release call in the whole application).So its absolutely guaranteed that Release is called only once at app shutdown. Is this design ok?   ;Quote:Original post by schupfIs this design ok?IMO, no.  Whenever you've got an object that is keeping an interface pointer, just use CComPtr<> and you generally won't need to care about AddRef or Release and your program will function properly, no matter what the rest of the world does with that interface pointer.  This is a basic COM idiom and is fundamental to keeping everything working properly.  I give a brief overview of COM and the use of CComPtr<> in Chapter 1. Introduction of my book.   ;Quote:All the objects with pointers to the device dont call AddRef() or Release. Only if the application is closed I call an exit() function with calls Release() (the only Release call in the whole application).So its absolutely guaranteed that Release is called only once at app shutdown. Is this design ok?Nope. Still has the same problems (nothing is guaranteed, you're not the only code involved, what if your application terminates abnormally, et cetera), plus it's probably leaking. There are some things you need to Release() because creating them implicitly references them.Use CComPtr<T>, and RAII. You are writing in C++, after all.   