On Mon, May 12, 2014 at 3:42 AM, Benoit Jacob <jacob.benoi...@gmail.com> wrote: > 2014-05-11 23:40 GMT-04:00 Boris Zbarsky <bzbar...@mit.edu>: > >> On 5/11/14, 7:50 PM, Chris Pearce wrote: >> >>> Should we be preferring mozilla::RefPtr in new code? >>> >>> Should we be replacing nsRefPtr with mozilla::RefPtr? >>> >> >> I would err on "no" for both, given https://bugzilla.mozilla.org/ >> show_bug.cgi?id=820257 >> >> > And to quote the description of this bug: > > Since bug 806279 <https://bugzilla.mozilla.org/show_bug.cgi?id=806279> it's >> fairly trivial to extend CC support to new pointer and container types. >> Just implement ImplCycleCollectionUnlink and ImplCycleCollectionTraverse. >> The possibly bigger difficulty here is not so much with RefPtr but with >> RefCounted, as it provides its own AddRef and Release, and for cycle >> collection we need custom AddRef and Release. >> > > Now that we have deprecated RefCounted in favor of nsISupportsImpl.h's > refcounting-implementing macros, that bigger difficulty is going away. > > We could easily: either add CC support for MFBT RefPtr, or, on the > contrary, remove MFBT RefPtr in favor of nsRefPtr, if needed by isolating > the CC bits of nsRefPtr (the overloads of ImplCycleCollectionUnlink and > ImplCycleCollectionTraverse for it) to make it independent of the rest of > XPCOM. > > It's only a matter of knowing which end result we would prefer :) > > Benoit > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform
We should get rid of RefPtr, just like we did the MFBT refcounting classes. The main thing stopping a mechanical search and replace is that the two smart pointers have different semantics around already_AddRefed/TemporaryRef :( - Kyle _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
