<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jul 17, 2014 at 5:42 PM, Nico Weber <span dir="ltr"><<a href="mailto:thakis@chromium.org" target="_blank">thakis@chromium.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class=""><div class="gmail_extra"><div class="gmail_quote">On Thu, Jul 17, 2014 at 4:43 PM, Lang Hames <span dir="ltr"><<a href="mailto:lhames@gmail.com" target="_blank">lhames@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div>Where unique_ptr fits the memory ownership model I'm all for using it. The syntactic overhead is a small price to pay for self-documentation and compile-time guarantees.</div></div></blockquote></div>

<br></div></div><div class="gmail_extra">+1. I liked the patches that added unique_ptrs I've seen so far. WebKit also heavily uses pointer classes (OwnPtr etc) heavily, and I think it works well there too.</div></div>

</blockquote></div><br></div><div class="gmail_extra">Branching off in a completely different direction, I want to point out that there is an abstraction penalty to passing unque_ptr by value.</div><div class="gmail_extra">
<br></div><div class="gmail_extra">By it's nature, unique_ptr is not trivially copyable: it has no copy ctor and it's move ctor and dtor are non-trivial.  Therefore, it cannot be passed in registers, or even directly on the stack on most platforms.  Typically, you end up with a hidden pointer to a temporary unique_ptr on the caller's stack when you pass or return one.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">However, ownership transfers are typically accompanied by new/delete, which are more expensive altogether than one more pointer chase.</div><div class="gmail_extra">
<br></div><div class="gmail_extra">2c</div></div>