I like leakPtr.<div><br></div><div>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.</div>
<div><br></div><div>dave</div><div><br><br><div class="gmail_quote">On Tue, Jun 29, 2010 at 10:40 AM, Darin Adler <span dir="ltr">&lt;<a href="mailto:darin@apple.com">darin@apple.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Jun 28, 2010, at 7:08 PM, Maciej Stachowiak wrote:<br>
<br>
&gt; - Yes, we should get rid of auto_ptr.<br>
&gt; - 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.<br>

<br>
</div>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.<br>
<br>
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.<br>
<br>
If we think the word &quot;leak&quot; 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.<br>
<div><div></div><div class="h5"><br>
 † †-- Darin<br>
<br>
_______________________________________________<br>
webkit-dev mailing list<br>
<a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a><br>
<a href="http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev" target="_blank">http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev</a><br>
</div></div></blockquote></div><br></div>