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 > >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. 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. Mike _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
