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