[webkit-dev] Why are PassRefPtr<>s used as function parameters?

[Maciej Stachowiak]

On Oct 29, 2009, at 12:56 PM, Darin Adler wrote:

> On Oct 27, 2009, at 10:55 AM, Jens Alfke wrote:
>
>> Looking at how refcounting is implemented in WebCore, I was  
>> surprised to find that there are a lot of functions/methods that  
>> take PassRefPtr<>s as parameters instead of regular pointers to  
>> those objects. I can't see any benefit to this, and it adds the  
>> overhead of a ref() and deref() at every call-site.
>
> Have you read the RefPtr document? It is at <http://webkit.org/coding/RefPtr.html 
> >.
>
> Only functions that take ownership of the passed-in objects should  
> take PassRefPtr. This makes it so we can optimally handle the case  
> where that object was just created and lets us hand off the  
> reference instead of having to do a round of reference count thrash.  
> If the function is going to be storing the value in a RefPtr, then  
> the PassRefPtr does not introduce any reference count thrash even if  
> the passed in object was not just created.
>
> It’s wrong for the HTMLNameCollection constructor to take a  
> PassRefPtr for its document argument because it doesn’t take  
> ownership of the document. So that one is definitely a mistake.

However, its base class HTMLCollection can take ownership. The  
HTMLNameCollection constructor misses out on the optimization though:

HTMLNameCollection::HTMLNameCollection(PassRefPtr<Document> document,  
CollectionType type, const String& name)
     : HTMLCollection(document.get(), type, document- 
 >nameCollectionInfo(type, name))
     , m_name(name)
{
}

Note that it passes document.get(), but also uses document after that  
so it couldn't just pass document. Thus, it probably shouldn't take a  
PassRefPtr (unless there is a clever way to fix it that I'm not seeing).

  - Maciej


>
> It is true that PassRefPtr arguments can be tricky as you mentioned  
> and the RefPtr document also mentions.
>
>    -- Darin
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev