Re: runtime error when setting pointer to interface to NULL
* Igor Tandetnik:
"Tim Roberts" <timr@probo.com> wrote in message
news:63gt845681118djem5f1ukltla69miebs2@4ax.com
"Igor Tandetnik" <itandetnik@mvps.org> wrote:
spIClarinet.Release();
Note .Release, not ->Release. It does the same as assigning NULL, but
perhaps in a more explicit and readable way.
There's more to it than that. spIClarinet->Release() bypasses the
smart pointer code in CComPtr
More to what than what? Was any part of "use .Release, not ->Release"
unclear?
I also reacted to the "there's more to it".
Besides, the OP is asking about _com_ptr_t, not CComPtr. With CComPtr,
spIClarinet->Release() wouldn't even compile.
Good samaritan that I am, for Tim, the technical: CComPtr::operator-> doesn't
return a pure T*, but returns the contained pointer downcasted to a
_NoAddRefReleaseOnCComPtr<T>*, which makes AddRef and Release private.
It's still possible to access AddRef and Release in other ways, but the
(compiler-specific) trick works in practice to catch such mistakes.
Cheers,
- Alf
PS: I think it's much better to just provide the technical info that one has
than to invite a back-and-forth exchange about it. Providing the technical info
=> everyone improves, scientific & engineering way. Making seemingly incorrect
statement based on special case knowledge => dominance games, political way
(although in this case it might have felt justified :-), I think, still ungood).
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?