In this case, HTMLCollection() keeps a reference to the object, so you can't safely pass in just a raw pointer. Since HTMLCollection keeps it around, you'd have to do the ref anyway.
-atw On Tue, Oct 27, 2009 at 10:55 AM, Jens Alfke <s...@chromium.org> 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. > > For example in HTMLNameCollection.h: > HTMLNameCollection(PassRefPtr<Document>, CollectionType, const String& > name); > > Why shouldn't this be > HTMLNameCollection(Document*, CollectionType, const String& name); > ? > > The use of PassRefPtr instead of RefPtr here also seems prone to trouble, > since inside the implementation of the method it could end up unexpectedly > clearing the parameter: > HTMLNameCollection::HTMLNameCollection(Document* doc, .... { > Ref<Document> otherDoc = doc; // This sets doc to NULL! > doc->something(); // CRASH > } > > I ran across this while trying to track down a reference leak of a Document > object. As one of my last resorts I set a watchpoint on the object's > m_refcount to see who refs/derefs it; but I had to give up because so many > method calls, including the one above, keep constantly twiddling the > refcount while passing the Document as a parameter. > > —Jens > _______________________________________________ > 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