On Tue, Dec 23, 2014 at 8:32 AM, Ehsan Akhgari <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>> 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>>> 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. > That's what we do in most of the places in the code. > Yes, I think this is unwise. -Ekr _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
