auto_ptr and COM

  • Thread starter Thread starter Doug Haber
  • Start date Start date
D

Doug Haber

Hi All,

Everyone tells me that auto_ptr is a good idea, but auto_ptr and COM don't
play nice. Can someone please explain why auto_ptr and COM don't like each
other and what a reasonable/typical solution is? My guess is that auto_ptr
will call the destructor on the COM object which is bad because it should
call Release(). I'd like to avoid manually calling Release(), because my
function has a bunch of places from which it can return, which I think means
calling Release() from different places or doing some nasty GOTO.

Thanks!
Doug
 
Hi All,

Everyone tells me that auto_ptr is a good idea, but auto_ptr and COM don't
play nice. Can someone please explain why auto_ptr and COM don't like each
other and what a reasonable/typical solution is? My guess is that auto_ptr
will call the destructor on the COM object which is bad because it should
call Release(). I'd like to avoid manually calling Release(), because my
function has a bunch of places from which it can return, which I think means
calling Release() from different places or doing some nasty GOTO.
Click to expand...

The std::auto_ptr class destroys objects by using the delete keyword, which
only works for objects created by new. COM pointers are not created by new,
but are instead obtained from QueryInterface and the like. You need to use
a COM smart pointer class, such as provided by MFC, ATL, or the compiler
itself in the form of _com_ptr_t.
 
Doug said:
Hi All,

Everyone tells me that auto_ptr is a good idea, but auto_ptr and COM don't
play nice. Can someone please explain why auto_ptr and COM don't like each
other and what a reasonable/typical solution is? My guess is that auto_ptr
will call the destructor on the COM object which is bad because it should
call Release(). I'd like to avoid manually calling Release(), because my
function has a bunch of places from which it can return, which I think means
calling Release() from different places or doing some nasty GOTO.
Click to expand...

Ah, then my recommendation would be the wrapper classes in ATL--check
out CComQIPtr and CComPtr class--both of them do automatic reference
counting for you. Alternatively like Doug said, _com_ptr_t is another
alternative.

The reason is that auto_ptr is not aware of COM's rule on AddRref and
Release, so you've got yourself a potential boom there when you mix the
two together!
 
Doug said:
Hi All,

Everyone tells me that auto_ptr is a good idea, but auto_ptr and COM don't
play nice. Can someone please explain why auto_ptr and COM don't like each
other and what a reasonable/typical solution is? My guess is that auto_ptr
will call the destructor on the COM object which is bad because it should
call Release(). I'd like to avoid manually calling Release(), because my
function has a bunch of places from which it can return, which I think means
calling Release() from different places or doing some nasty GOTO.
Click to expand...

In addition to what everyone else said, boost::shared_ptr (aka
std::tr1::shared_ptr) does work with COM:
http://www.boost.org/libs/smart_ptr/sp_techniques.html#com

Tom
 
I'm not sure about the Netiquette - since I don't really have anything else
to say but thanks all!

-D
 
Back
Top