On 12/26/2014 03:08 PM, Aryeh Gregor wrote:
On Mon, Dec 22, 2014 at 11:10 PM, Jeff Muizelaar <jmuizel...@mozilla.com> wrote:
Possible solutions would be to:
- remove implicit conversions to T*
If this were done, I think we should change the calling convention for
functions that take pointers to refcounted classes. The convention is
broken anyway: the convention is supposed to be that the caller holds
a strong reference, but the parameter type is a raw pointer, which
does not enforce this. This has led to at least one sec-critical that
I know of, IIRC, where the caller did not hold a strong reference
locally, and the callee wound up freeing it. There have probably been
lots more that I don't know of.
I've thought in the past of a RefParam<T> type, which would be for use
only as a function parameter. nsRefPtr<T>/nsCOMPtr<T> would
implicitly convert to it, but raw pointers would not implicitly
convert to it. And it would implicitly convert to a raw pointer,
which is safe as long as the nsRefPtr<T>/nsCOMPtr<T> that it was
initialized with was a local variable (and not a member or global).
Thus to the callee, it would behave exactly like a raw pointer. The
only difference is the caller is not allowed to pass a raw pointer.
With this change, we wouldn't need to convert from nsRefPtr<T> to T*
often, as far as I can think of. It would also preserve binary
compatibility with XPCOM AFAICT, because RefParam<T> would have
trivial constructor and destructor and no virtual functions. It also
would add no addref/release. It would just help the compiler catch
cases where raw pointers are being passed to functions that expect the
caller to hold a strong reference, which would perhaps allow us to
sanely remove the implicit conversion from nsRefPtr<T> to T*.
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.
- add operator T* explicit and operator T* && = delete // this will be
available in GCC 4.8.1 and MSVC 2014 Nov CTP
What would this do? I see that deleting operator T* && would prevent
a temporary nsRefPtr<T> from converting unsafely to a raw pointer,
which would address that objection to removing already_AddRefed. But
what does the first part do?
On Tue, Dec 23, 2014 at 1:21 AM, Ehsan Akhgari <ehsan.akhg...@gmail.com> wrote:
Are there good use cases for having functions accept an nsRefPtr<T>&? If
not, we can outlaw them.
Do we have a better convention for an in/out parameter that's a
pointer to a refcounted class? editor uses this convention in a
number of functions for "pass me a node/pointer pair as input, and
I'll update it to the new value while I'm at it." If there's a good
substitute for this, let me know and I'll use it in the future when
cleaning up editor code.
nsCOM/RefPtr<>& is a good option for inouts.
(Tough one should avoid inouts when possible.)
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
