On Sat, Dec 27, 2014 at 12:34 AM, smaug <sm...@welho.com> wrote:
> How would this setup help with the case when one passes
> nsCOMPtr/nsRefPtr member variable as a param? I believe that has been the
> most common issue
> with "caller-should-keep-the-parameter-alive" - one just doesn't remember to
> make sure the
> value of the member variable can't be replaced with some other value while
> calling the method.
It wouldn't. I didn't go into it, but I did think of this, and I
think that the way to handle it would be to define
template<class T> class RefMember<T> : public nsRefPtr<T> {}
and delete the conversion from RefMember<T> to RefParam<T>, then use
static analysis to enforce that nsRefPtr/nsCOMPtr as a member variable
is a compiler error. Of course we'd also need a way to manually avoid
the addref/release in cases where the caller cares about perf and
knows it's safe, maybe a helper function like StrongRefAlreadyHeld(),
which should be a ref flag in reviews unless it's really necessary.
Also we should have a RawParam<T> that behaves like a raw pointer, but
accepts implicit conversions from any pointer type, strong or not.
This would be used for functions that care about perf and are
absolutely certain they will not release the parameter across the call
(e.g., nsINode::Contains). This is needed because nsRefPtr<T> won't
convert to T*, and T* won't convert to RefParam<T>, but functions like
this want to accept either T* or nsRefPtr<T>, so they need a new type.
> nsCOM/RefPtr<>& is a good option for inouts.
> (Tough one should avoid inouts when possible.)
There are a significant number of functions in editor where I don't
see a nicer solution than in/out parameters. (But that's not to say I
disagree with you -- one should avoid editor when possible. :) )
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
