CComPtr vs. _COM_SMARTPTR_TYPEDEF macro
Back 9
Some people in my group say that using _COM_SMARTPTR_TYPEDEF macro is much
safer than using CComPtr.
I am just wondering how come it is true.
What is the strenths to use the macro over CComPtr?
Back9
The March Hare [MVP]
> Some people in my group say that using _COM_SMARTPTR_TYPEDEF macro is much
> safer than using CComPtr.
Why do they say that? I have not heard any problems with safety with
CComPtr.
--
Please read this before replying:
1. Dshow & posting help: http://tmhare.mvps.org/help.htm
2. Trim & respond inline (please don't top post or snip everything)
3. Benefit others: follow up if you are helped or you found a solution
Alessandro Angeli
None? The macro expands to a typedef that uses MSVC's
_com_ptr_t template while CComPtr is ATL's implementation of
a smart pointer. Using the macro is a time-safer when you
use MSVC's smart pointers, especially when you need to
declare several variables of the same type, since _com_ptr_t
has a nightmarish syntax. But that doesn't make it safer
than CComPtr, which is a completely separate (and simpler)
implementation.
_com_ptr_t throws _com_error while CComPtr I think throws
CAtlException.
_com_ptr_t calls QI while CComPtr doesn't (but CComQIPtr
does).
--
// Alessandro Angeli
// MVP :: DirectShow / MediaFoundation
// mvpnews at riseoftheants dot com
// http://www.riseoftheants.com/mmx/faq.htm
The March Hare [MVP]
> CComPtr is ATL's implementation of
> a smart pointer.
I think this is the reason some people, like G., prefer the macro. They
don't want to introduce the ATL dependency on client's projects. I don't
think it has to do with safety.
Alessandro Angeli
> I think this is the reason some people, like G., prefer
> the macro. They don't want to introduce the ATL
> dependency on client's projects. I don't think it has to
> do with safety.
It's not like _com_ptr_t is plain ANSI C++ either, since it
is an MSVC++ extension of the standard library. To be "pure"
you need to bring along your own smart pointer template or
not use smart pointers. I advocate the latter, but I am a
minority :-)
Back 9
They say there is well-known issue of CComPtr. Unfortunately they could not
search the article on the web.
Thank,
Back9
The March Hare [MVP]
> Then is there any memory leak issue with CComPtr that I should be aware of?
Not that I am aware of. I've been using them in my app for over six years
and haven't seen one.
> They say there is well-known issue of CComPtr. Unfortunately they could not
> search the article on the web.
I did a search and didn't see anything about memory leaks with CComPtr.
Geraint Davies
<themar...@alice.in.wonderland> wrote:
>I think this is the reason some people, like G., prefer the macro. They
>don't want to introduce the ATL dependency on client's projects. I don't
>think it has to do with safety.
[sorry -- bit behind with replying]
Yes, that and the behaviour is slightly different. The macro version
releases the object if you take the address. This sounds like a
hideous side-effect behaviour, but in fact it works just fine
pSomething->ReturnMeAPointer(&pMySmartPtr);
If the smart pointer was not null before the call, ATL will assert but
the MSVC macro will release the pointer.
There's also a difference in the null testing which works the other
way.
G