On Tuesday 2014-08-12 18:40 +0300, Aryeh Gregor wrote: > On Tue, Aug 12, 2014 at 6:29 PM, L. David Baron <[email protected]> wrote: > > This is done very commonly when we know some other data structure > > (or the lifetime of |this|) owns the object, and will continue to > > across the lifetime of the function. > > > > For example, if I open content/base/src/Element.cpp, I see this > > pattern 5 times in the first 325 lines of the file. (Three > > nsIDocument*, one nsIContent*, one nsIPresShell*.) > > If you know something else is holding a strong reference, why is it a > problem to assign the result of a function that returns > already_AddRefed<T> to a local variable of type T*? If the local > variable's usage is otherwise legitimate, that assignment is perfectly > safe and there's no reason for any compiler errors.
In these cases we document that it's likely safe for callers to do this by having those getters return raw pointers. Getters that require reference-counting return already_AddRefed. Thus the designer of the API makes a choice about whether the caller is required to reference-count the result. Our initial switch to use getters with raw pointers rather than reference-counting getters (as part of deCOMtamination) was a substantial performance win (probably at least 10% on general across-the-board performance metrics). On the other hand, getters that might return a new object must return already_AddRefed<T> to ensure the caller takes ownership of that reference. -David -- 𝄞 L. David Baron http://dbaron.org/ 𝄂 𝄢 Mozilla https://www.mozilla.org/ 𝄂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914)
signature.asc
Description: Digital signature
_______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
