On Mon, Sep 12, 2016 at 10:53 AM, Daniel Holbert <dholb...@mozilla.com> wrote: > On 08/12/2014 07:59 AM, Benjamin Smedberg wrote: >> But now that nsCOMPtr/nsRefPtr support proper move constructors, [...] >> Could we replace every already_AddRefed return value with a nsCOMPtr? > > I have a variant of bsmedberg's original question here. He asked about > return values, but I'm wondering: > Could we replace every already_AddRefed *function-parameter* with a move > reference to a RefPtr/nsCOMPtr? > > (Sorry if this was answered in this thread; I skimmed through it & > didn't find a definitive answer immediately. It seems like this might be > a strictly easier thing to fix up, as compared to return values.) > > As a concrete example, at this usage site... > https://dxr.mozilla.org/mozilla-central/rev/1851b78b5a9673ee422f189b92e5f1e86b82a01c/dom/base/nsDOMMutationObserver.h#468 > ...is there any benefit to us using > already_AddRefed<nsPIDOMWindowInner>&& aOwner, instead of > nsCOMPtr<nsPIDOMWindowInner>&&? > > (I believe we have the "already_AddRefed as a parameter" pattern in our > code in order to avoid an extra addref/release when ownership is being > transferred into a function. But, RefPtr/nsCOMPtr with move references > would let us do that just as well, more concisely & less arcanely.)
There's an important semantic difference: something that takes a move reference to a smart pointer is not obligated to accept the reference. If I do smartptr.forget() I know afterwards that smartptr is empty and the reference that used to exist in it is Not My Problem (TM), whereas if I call something with a move reference to smartptr I may have to handle the error case, depending on what the callee does. Those sorts of non-local effects, IMHO, make code harder to read. - Kyle _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
