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?
On Wed, 2 Apr 2008 14:59:01 -0700, Back 9 wrote: > 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
> 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?
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).
On Wed, 2 Apr 2008 18:34:04 -0400, Alessandro Angeli wrote: > 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.
-- 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
> 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 :-)
Then is there any memory leak issue with CComPtr that I should be aware of? They say there is well-known issue of CComPtr. Unfortunately they could not search the article on the web.
> On Wed, 2 Apr 2008 14:59:01 -0700, Back 9 wrote:
> > 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
On Thu, 3 Apr 2008 05:37:02 -0700, Back 9 wrote: > 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.
-- 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
On Wed, 2 Apr 2008 17:02:37 -0600, "The March Hare [MVP]"
<themarchh...@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.
|
