Summary: | Made Weak<T> single-owner, adding PassWeak<T> | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Geoffrey Garen <ggaren> | ||||
Component: | New Bugs | Assignee: | Geoffrey Garen <ggaren> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | kling, mhahnenberg, sam | ||||
Priority: | P2 | ||||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Attachments: |
|
Description
Geoffrey Garen
2012-02-15 14:06:14 PST
Created attachment 127241 [details]
Patch
*** Bug 76335 has been marked as a duplicate of this bug. *** Comment on attachment 127241 [details]
Patch
One idiom we have been adopting with other smart pointers in WebKit is that you never explicitly construct the Pass type, but rather have a friend function that does it, e.g. adoptPtr() and adoptRef(). Not sure that is necessary here but wanted to mention it.
Comment on attachment 127241 [details] Patch Attachment 127241 [details] did not pass qt-ews (qt): Output: http://queues.webkit.org/results/11529842 > One idiom we have been adopting with other smart pointers in WebKit is that you never explicitly construct the Pass type, but rather have a friend function that does it, e.g. adoptPtr() and adoptRef(). Not sure that is necessary here but wanted to mention it.
Why do we do that? I might be able to replicate something similar for PassWeak<T> if I understand the intention. It's not trivial replicable, though, because a PassWeak<T> needs to allocate a backing handle, which the client doesn't initially have available for adoption.
... I might be able to make it work in a future patch that makes the backing for a *Weak<T> an explicit object. Committed r108010: <http://trac.webkit.org/changeset/108010> |