On 2013-07-19 7:04 PM, Mike Hommey wrote:
On Fri, Jul 19, 2013 at 03:45:13PM -0400, Ehsan Akhgari wrote:
On 2013-07-19 3:26 PM, Ehsan Akhgari wrote:
On 2013-07-18 10:46 PM, Mike Hommey wrote:
On Thu, Jul 18, 2013 at 08:54:02PM -0500, Joshua Cranmer ? wrote:
On 7/18/2013 7:15 PM, Robert O'Callahan wrote:
On Fri, Jul 19, 2013 at 3:34 AM, Ehsan Akhgari
<ehsan.akhg...@gmail.com>wrote:
On 2013-07-18 5:48 AM, mscl...@googlemail.com wrote:
r-value references 4.3@ 10.0! Yes
This is very useful. I believe the JS engine already rolls their
own tricks to implement this semantics.
With this we can get rid of already_AddRefed and just pass
nsRefPtr/nsCOMPtr/RefPtr around, right?
I believe so. We can also add a non-broken variant of nsAutoPtr
modeled after std::unique_ptr (allows moves but not copies).
Note that STL is another story. We're not using libstdc++ that comes
with the compiler on android and b2g. We use STLport instead, and
STLport has, afaik, no support for C++11 STL types. So, while we can
now fix nsAutoPtr to use move semantics instead of copy semantics,
we can't use std::unique_ptr.
Does this mean that we can't use std::move and std::forward either?
Indeed
Sadface. I filed bug 896100 about this, and I'll write a patch for it soon.
In that case, we need MFBT versions of those, because working with
rvalue references without those two functions is a pain!
Good news is that implementing these functions should be really easy.
Also, is there a reason that we don't build on Android with the
libstdc++ that ships with the toolchain?
For one, the fact that it actually doesn't work currently (at least, it
didn't last i heard someone tried) doesn't help.
Heh, yeah it doesn't, indeed!
And I think that when stlport was chosen, using the GNU stl made the
android package significantly larger. But then, we weren't statically
linking stlport, so this may have changed.
Also note that because we're building for specific targets that are not
exactly those for which we have prebuilt libraries coming in the NDK,
we're actually building stlport ourselves. We'd have to do the same for
the GNU stl if we chose to use it, and we have no current support for
that in the build system (the build system only knows how to build
against the prebuilt one, and that's what doesn't even work). I don't
know how easy it is to compile the GNU stl outside of building gcc.
Ah, I have feeling that doing that is actually very hard... Let's
declare defeat on this for now (unless people want to do all of this
work!) and move on with bug 896100. Once we have that, I will try to
find some time to see if we can kill already_AddRefed. That is one
class I won't miss. :-)
Ehsan
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
