On Mon, May 12, 2014 at 1:03 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com> wrote: > On 2014-05-12, 9:36 AM, Kyle Huey wrote: >>> >>> 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. > > > s/deprecate/outlaw/.
Indeed. \o/ > > >>> 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 :) > > > So, is there an actual advantage to using RefPtr over nsRefPtr? And is > there any reason why we could not provide the same functionality on > nsRefPtr? Not afaict. > >> 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 :( > > > Do you mind talking about about the semantic differences? I haven't looked > into it too much yet... IIRC TemporaryRef's dtor releases the ref. already_AddRefed lets you leak (though it asserts fatally in debug builds). - Kyle _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
