On Tue, Dec 23, 2014 at 8:53 AM, Ehsan Akhgari <[email protected]> wrote:
> On 2014-12-23 11:36 AM, Eric Rescorla wrote: > >> >> >> On Tue, Dec 23, 2014 at 8:32 AM, Ehsan Akhgari <[email protected] >> <mailto:[email protected]>> wrote: >> >> On 2014-12-23 10:38 AM, Eric Rescorla wrote: >> >> >> >> On Tue, Dec 23, 2014 at 6:48 AM, Ehsan Akhgari >> <[email protected] <mailto:[email protected]> >> <mailto:ehsan.akhgari@gmail.__com >> >> <mailto:[email protected]>>> wrote: >> >> On 2014-12-22 6:52 PM, Eric Rescorla wrote: >> >> >> >> On Mon, Dec 22, 2014 at 3:35 PM, L. David Baron >> <[email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>> >> <mailto:[email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>>> 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. -Ekr _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
