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 <da...@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@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev