On 2014-12-22 6:35 PM, L. David Baron 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.
Well, I did pick that project up but for some reason it was never
finished (don't remember what.) But that's not what I was talking
about. See bug 1114683 for an example of what I was talking about.
* 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?)
It indeed is, but that doesn't make it a good use case. The editor/
stuff is mostly workarounds for the lack of things such as
already_AddRefed, getter_AddRefs and so on. I personally cannot think
of a good use case for it.
* using C-style casts (or reinterpret_cast) to make things compile
C-style casts would not be able to make anything compile if the
class doesn't provide an operator T*(). I'm not sure what you mean
here.
Sorry, originally wrote reinterpret_cast and then changed what I
wrote at the last minute because I was thinking about casting
between pointer types.
Same thing with both types of casts. :-)
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
