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*. > - 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. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
