[webkit-dev] Lets use PassRefPtr for arguments less; lets use RefPtr for locals and data members more

[David Levin]

On Mon, Jun 20, 2011 at 9:39 PM, Alexey Proskuryakov <ap at webkit.org> wrote:

>
> 20.06.2011, в 21:29, David Levin написал(а):
>
> > Here's a few benefits:
> > 1. It makes the code more self-documenting. It clearly indicates that
> this function intends to take a reference to the item.
> > 2. It is consistent with the rules for PassOwnPtr. It is nice to have one
> set of things in mind that are consistent.
> > 3. Just like one shouldn't document a function based on who calls it
> because that may change, it makes sense to base the argument types on the
> how the function uses them not on the callers.
>
> 1 and 3 sound very closely related. Yet I'm not sure if they are good.
>

True, I didn't think of it that way when I wrote it. :) I feel like they are
good, but I could be wrong. (I always have felt like knowing who is owning
something is one of those tricky things when reading code so I've
appreciated this but it may be of limited value when taking about ref
counted items.)

And I like 2 but it isn't critical.


>
> PassRefPtr is useful even if the function doesn't take any kind of
> ownership. It's useful when callers want to get rid of ownership, and then
> they can do that efficiently.
>

I don't understand this. How it is more efficient to pass ownership if a
function isn't taking ownership? It seems like passing in a raw pointer
would be the most efficient in this case.


> As Maciej mentioned, eventually we may be able to get rid of PassRefPtr,
> and use C++0x move semantics. But applicability of move semantics also
> depends on how a function is called, not on what it is going to do with its
> arguments.
>

Good point. Makes sense.

dave


>
> - WBR, Alexey Proskuryakov
>
> _______________________________________________
> 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/20110620/1598c07b/attachment.html>