On Mon, Jul 22, 2013 at 10:01 PM, Rob Arnold <tell...@gmail.com> wrote: > That idiom seems dangerous by itself; the assumption it makes is that the > reference will outlive the callee but that isn't actually enforced anywhere > (you could write UseFoo(nsRefPtr<T>(new T)) and Bad Things would happen; > there are less obvious ways to write this). I would rewrite UseFoo to take > an const nsRefPtr<nsIFoo>& instead and then you don't have to worry about > these issues.
It is dangerous. See discussion here, which Ralph Giles linked to: https://bugzilla.mozilla.org/show_bug.cgi?id=767178 In particular, I've fixed a crash bug and a security bug caused by this idiom, and I'm sure there are many more like them. (Although getting rid of mutation events would help a lot!) However, just making the argument be a refptr means the function call does addref and release on every call even if the caller is already holding a reference, which has been deemed unacceptable from a perf standpoint. A couple of suggestions were made in the linked-to bug to ameliorate the problem, but nobody has come up with a scheme that gives the same safety as nsRefPtr-as-param-type without unacceptable runtime cost. Most of the problem could be solved if you required that nsCOMPtr/nsRefPtr only be used as a local variable (in particular, not member variables) and introduced a type COMParam/RefParam or something that implicitly converted from nsCOMPtr/nsRefPtr without addref/release but didn't convert implicitly from raw pointer at all, so the caller would have to wrap it in something that did the addref/release. Then -- in theory -- the caller should hold a reference throughout the function call, unless you do something really obnoxious like store a non-const reference to the local variable somewhere that the callee can get at. Callees that were really super duper sure they didn't need a strong reference could still use the raw pointer for parameters if they wanted to save the addref/release. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
