On 8/12/2014 9:59 AM, Benjamin Smedberg wrote:
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?
The rationale for why we still had it was that:
nsIFoo *foobar = ReturnsACOMPtr();
silently leaks. I've pointed out before that we could fix this by adding
a nsCOMPtr<T>::operator T*() && = delete; operator, but that's a gcc
4.8.1/msvc 2013 November CTP minimum requirement.
--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
