[webkit-dev] Tightening up smart pointer usage rules
levin at chromium.org
Tue Jun 29 11:07:08 PDT 2010
I like leakPtr.
Personally, releasePtr() is so close to release() (which is safe) that I
could easily overlook it in a code review and not realize that it hands off
a raw pointer with a ref count on it.
On Tue, Jun 29, 2010 at 10:40 AM, Darin Adler <darin at apple.com> wrote:
> On Jun 28, 2010, at 7:08 PM, Maciej Stachowiak wrote:
> > - Yes, we should get rid of auto_ptr.
> > - I can imagine a leakPtr function being more self-documenting than
> adoptPtr(...).releasePtr() when it appears in code, but on the other hand
> the greater convenience may lead to using it carelessly. On the third hand,
> it will definitely stand out if it appears in a patch.
> The main benefit of adoptPtr(...).releasePtr() is that the adoptPtr can
> stay with the new when refactoring, and the releasePtr can stay with the
> intentional leak.
> Any call site using releasePtr needs to be examined carefully to see it
> does not leak. That’s different from functions like release that do not pose
> that sort of risk, but similar to releaseRef, which does.
> If we think the word "leak" is key to clarity here, renaming releasePtr to
> leakPtr would be one option. I don’t think we want a single function
> combining the adoptPtr and releasePtr behavior.
> -- Darin
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev