Maybe we should call ours mozilla::move and mozilla::forward so that we can change to std::move and std::forward with minimal pain? On Jul 19, 2013 4:36 PM, "Ehsan Akhgari" <ehsan.akhg...@gmail.com> wrote:
> 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<https://lists.mozilla.org/listinfo/dev-platform> > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
