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>> 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>>> 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>>>> 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.
That being said, I think we can and should make the compiler more aware
of the semantics of our smart pointers, to ensure that the unboxing
operation can only be performed when you hold an owning pointer to the
object. Once we get there, unboxing would be safe.
That's what we do in most of the places in the code.
Yes, I think this is unwise.
For the better or worse, anything that uses XPCOM needs to stick to
passing in raw interface pointers, since anything else would be an ABI
incompatible change (assuming that ABI compat with MSCOM is still a goal.)
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
