As far as I know, the only downside in replacing already_AddRefed by nsCOMPtr would be to incur more useless calls to AddRef and Release. In the case of "threadsafe" i.e. atomic refcounting, these use atomic instructions, which might be expensive enough on certain ARM CPUs that this might matter. So if you're interested, you could take a low-end ARM CPU that we care about and see if replacing already_AddRefed by nsCOMPtr causes any measurable performance regression.
Benoit 2014-08-12 10:59 GMT-04:00 Benjamin Smedberg <benja...@smedbergs.us>: > Just reading bug 1052477, and I'm wondering about what are intentions are > for already_AddRefed. > > In that bug it's proposed to change the return type of NS_NewAtom from > already_AddRefed to nsCOMPtr. I don't think that actually saves any > addref/release pairs if done properly, since you'd typically .forget() into > the return value anyway. But it does make it slightly safer at callsites, > because the compiler will guarantee that the return value is always > released instead of us relying on every already_AddRefed being saved into a > nsCOMPtr. > > But now that nsCOMPtr/nsRefPtr support proper move constructors, is there > any reason for already_AddRefed to exist at all in our codebase? Could we > replace every already_AddRefed return value with a nsCOMPtr? > > --BDS > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
