Re: nsRefPtr vs RefPtr

Brian Smith wrote: On Mon, May 12, 2014 at 9:36 AM, Kyle Huey wrote: 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/TemporaryR

Re: nsRefPtr vs RefPtr

On 2014-05-13, 11:46 AM, Tim Abraldes wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The chromium IPC code is ours now, so we can mdify it as needed. Not sure about the Chromium sandbox code. The Chromium sandbox code lives at "security/sanbox" in the tree. AIUI, we wanted to be able to

Re: nsRefPtr vs RefPtr

On Mon, May 12, 2014 at 9:36 AM, Kyle Huey wrote: > 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 :( Nit: Ar

Re: nsRefPtr vs RefPtr

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > The chromium IPC code is ours now, so we can mdify it as needed. > Not sure about the Chromium sandbox code. The Chromium sandbox code lives at "security/sanbox" in the tree. AIUI, we wanted to be able to pull upstream changes easily so we've avoide

Re: nsRefPtr vs RefPtr

On 5/13/14 9:25 AM, Ehsan Akhgari wrote: The chromium IPC code is ours now, so we can mdify it as needed. Not sure about the Chromium sandbox code. Also AFAIK RefPtr was first incorporated into our code base as a way to replace wtf::RefPtr for YARR but I have no evidence that it actually ever

Re: nsRefPtr vs RefPtr

On 5/13/2014 11:25 AM, Ehsan Akhgari wrote: The chromium IPC code is ours now, so we can mdify it as needed. Not sure about the Chromium sandbox code. Also AFAIK RefPtr was first incorporated into our code base as a way to replace wtf::RefPtr for YARR but I have no evidence that it actually eve

Re: nsRefPtr vs RefPtr

On 2014-05-12, 4:48 PM, Mike Hommey wrote: On Mon, May 12, 2014 at 04:46:18PM -0700, Kyle Huey wrote: On Mon, May 12, 2014 at 2:46 PM, Mike Hommey wrote: On Mon, May 12, 2014 at 09:36:22AM -0700, Kyle Huey wrote: We should get rid of RefPtr, just like we did the MFBT refcounting classes. The

Re: nsRefPtr vs RefPtr

On 2014-05-12, 2:46 PM, Mike Hommey wrote: On Mon, May 12, 2014 at 09:36:22AM -0700, Kyle Huey wrote: 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 aroun

Re: nsRefPtr vs RefPtr

Oh and regarding 3rd-party code, that is not a different problem from what we have already discussed above: The only hard constraint here is that some 3rd-party code does not want to depend on XPCOM. That's fine; as discussed above, we could easily move out of XPCOM (presumably into MFBT) the part

Re: nsRefPtr vs RefPtr

If the semantics difference between TemporaryRef and already_AddRefed are the main factor blocking us here, could we at least make progress by temporarily having the two coexist, i.e. a transition plan roughly as follows: 1) Introduce a nsTemporaryRef behaving like TemporaryRef but cooperating wi

Re: nsRefPtr vs RefPtr

On Mon, May 12, 2014 at 04:46:18PM -0700, Kyle Huey wrote: > On Mon, May 12, 2014 at 2:46 PM, Mike Hommey wrote: > > On Mon, May 12, 2014 at 09:36:22AM -0700, Kyle Huey wrote: > >> We should get rid of RefPtr, just like we did the MFBT refcounting classes. > >> > >> The main thing stopping a mecha

Re: nsRefPtr vs RefPtr

On Mon, May 12, 2014 at 2:46 PM, Mike Hommey wrote: > On Mon, May 12, 2014 at 09:36:22AM -0700, Kyle Huey wrote: >> 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 diffe

Re: nsRefPtr vs RefPtr

On Mon, May 12, 2014 at 09:36:22AM -0700, Kyle Huey wrote: > 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 :(

Re: nsRefPtr vs RefPtr

On Mon, May 12, 2014 at 1:03 PM, Ehsan Akhgari wrote: > On 2014-05-12, 9:36 AM, Kyle Huey wrote: >>> >>> Since bug 806279 >>> it's fairly trivial to extend CC support to new pointer and container types. Just implement ImplCycleCo

Re: nsRefPtr vs RefPtr

On 2014-05-12, 9:36 AM, Kyle Huey wrote: Since bug 806279 it's fairly trivial to extend CC support to new pointer and container types. Just implement ImplCycleCollectionUnlink and ImplCycleCollectionTraverse. The possibly bigger difficulty he

Re: nsRefPtr vs RefPtr

On Mon, May 12, 2014 at 3:42 AM, Benoit Jacob wrote: > 2014-05-11 23:40 GMT-04:00 Boris Zbarsky : > >> 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" fo

Re: nsRefPtr vs RefPtr

2014-05-11 23:40 GMT-04:00 Boris Zbarsky : > 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=820

Re: nsRefPtr vs RefPtr

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 -Boris ___

nsRefPtr vs RefPtr

We have two reference counted smart pointer implementations; nsRefPtr and the newer mozilla::RefPtr. Should we be preferring mozilla::RefPtr in new code? Should we be replacing nsRefPtr with mozilla::RefPtr? Cheers, Chris P. ___ dev-platform mailing