[webkit-dev] Tightening up smart pointer usage rules

[David Levin]

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.

dave


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
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100629/bd37eb8c/attachment.html>