On 2014-12-23 12:51 PM, Eric Rescorla wrote:
On Tue, Dec 23, 2014 at 8:53 AM, Ehsan Akhgari <ehsan.akhg...@gmail.com <mailto:ehsan.akhg...@gmail.com>> wrote: On 2014-12-23 11:36 AM, Eric Rescorla wrote: On Tue, Dec 23, 2014 at 8:32 AM, Ehsan Akhgari <ehsan.akhg...@gmail.com <mailto:ehsan.akhg...@gmail.com> <mailto:ehsan.akhgari@gmail.__com <mailto:ehsan.akhg...@gmail.com>>> wrote: On 2014-12-23 10:38 AM, Eric Rescorla wrote: On Tue, Dec 23, 2014 at 6:48 AM, Ehsan Akhgari <ehsan.akhg...@gmail.com <mailto:ehsan.akhg...@gmail.com> <mailto:ehsan.akhgari@gmail.__com <mailto:ehsan.akhg...@gmail.com>> <mailto:ehsan.akhgari@gmail. <mailto:ehsan.akhgari@gmail.>____com <mailto:ehsan.akhgari@gmail.__com <mailto:ehsan.akhg...@gmail.com>>>> wrote: On 2014-12-22 6:52 PM, Eric Rescorla wrote: On Mon, Dec 22, 2014 at 3:35 PM, L. David Baron <dba...@dbaron.org <mailto:dba...@dbaron.org> <mailto:dba...@dbaron.org <mailto:dba...@dbaron.org>> <mailto:dba...@dbaron.org <mailto:dba...@dbaron.org> <mailto:dba...@dbaron.org <mailto:dba...@dbaron.org>>> <mailto:dba...@dbaron.org <mailto:dba...@dbaron.org> <mailto:dba...@dbaron.org <mailto:dba...@dbaron.org>> <mailto:dba...@dbaron.org <mailto:dba...@dbaron.org> <mailto:dba...@dbaron.org <mailto:dba...@dbaron.org>>>>> wrote: On Monday 2014-12-22 18:21 -0500, Ehsan Akhgari wrote: > On 2014-12-22 6:07 PM, L. David Baron wrote: > >On Monday 2014-12-22 17:54 -0500, Ehsan Akhgari wrote: > >>On 2014-12-22 4:56 PM, L. David Baron wrote: > >>>I think removing implicit conversions to T* will make a lot of code > >>>in the tree uglier (".get()" everywhere). That might, in turn, > >>>encourage people to do worse things to avoid having to write .get() > >>>everywhere; it's worth thinking about what those things will be. > >> > >>Do you have any examples of those bad things? (FWIW I'm all for > >>making bad things impossible.) > > > >* using raw pointers instead of smart pointers > > I am planning on making that impossible [*] in 2015. I presume you mean making direct calls to AddRef and Release impossible, and not raw pointers in general. > >* making functions take nsRefPtr<T>& instead of T*, leading to > > unnecessary risk of mutation of the caller's pointer and extra > > indirection > > > > * ... and perhaps the same for getters > > Are there good use cases for having functions accept an > nsRefPtr<T>&? If not, we can outlaw them. I've seen a few, but it's probably rare. (Is that pattern still used all over editor?) I frequently use const RefPtr<T>&? or const UniquePtr<T>&. Is this something that people object to? What is your use case? I guess it's not transferring ownership. I don't really understand why one would use these classes as argument when they're not trying to worry about ownership... You're already holding a SmartPtr<T> and you want to pass it to a function which operates on it, but since, as you say, you're not transferring ownership, you don't need to increment or decrement the ref ct. Why not pass the raw pointer to the function? My general theory is that smart pointers, once boxed, should never be unboxed. The major arguments I see for unboxing is performance, but if you pass a ref, then you don't have the increment/decrement cycle. But still you'd need to double-deref the pointer to use it in the callee (assuming that things do not get inlined.) Also, I think that general theory is only useful if you actually manage to stick to it all along the way. Because of the point below, that would probably be a lost cause in our code base, and all you need to screw things up is a single place where the smart pointer is unboxed. I think this (and the issue below) may be a matter of which parts of the code you're working in. I mostly do self-contained stuff which doesn't need to interact with XPCOM and which uses a lot of smart pointers internally, so I'm not overworried about having to convert to raw pointers.
That's fair. But I also have a tendency towards free abstractions over ones that cost us runtime perormance...
_______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
