On Tuesday 2014-08-12 10:59 -0400, 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.
Bug 967364 did already add assertions to guarantee this. > 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? Two thoughts: (1) I think it introduces a somewhat major coding style risk, in that it makes it possible to accidentally assign the value of a function that returns a reference into a raw pointer, which isn't possible with already_AddRefed. In other words, today, you can write: T* t = GetT() and know that as long as the code is following conventions correctly and using already_AddRefed when a reference is returned, this won't compile if an nsCOMPtr is required. If we change to returning nsCOMPtr instead of returning already_AddRefed, this won't be the case, and the code will end up having a dangling pointer to a potentially-deleted object. (2) If we agree it's a good idea from a coding style perspective, it's probably worth having a look that the generated code is equally efficient, given how widely used it is in our codebase. Because of (1), I probably lean against this change (and against bug 1052477), unless I'm missing something that makes (1) not be true. -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 dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
