On Tue, Jul 30, 2013 at 10:50:39PM -0400, Ehsan Akhgari wrote: > On Tue, Jul 30, 2013 at 7:40 PM, Brian Smith <br...@briansmith.org> > wrote: > > > On Fri, Jul 19, 2013 at 4:46 AM, Mike Hommey <m...@glandium.org> > > wrote: > > > > > 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. > > > > > > > I saw bug 896100 [1] wants to add mozilla::Move and > > mozilla::Forward. Obviously, that is a clear improvement that we > > can build on. > > > > Agreed. > > > > But, shouldn't we just name these std::move and std::forward and use > > these implementations only when we're using STLPort? I know we're > > not supposed to add stuff to the std:: namespace normally, but > > that's exactly what STLPort is doing. > > > > We've avoided doing this so far in MFBT for everything in the language > or the standard library that we had to reimplement ourselves. I'm not > aware of any practical problems in putting things in the std namespace > (besides watching out for name clashes, which most standard library > implementations avoid by either using nested namespaces for their > implementation helpers, or symbols with underscore at the beginning of > their name which are supposed to be reserved for implementations -- > but real code in the while violates that all the time.) But it still > feels a bit unclean to put things into namespace std. Is there a good > reason why we should do that in this case? > > (Also remember that STLport is an STL implementation, so it is > entirely ok for them to put things into namespace std!)
Note that if STLport is the only thing preventing us from using some C++11 std:: features, we can implement them and contribute them upstream. That being said, it does look like the STLport git has unique_ptr, forward and move. It's not part of any release, though, and I'm not sure how good the current trunk is. The version we're currently using is 5.2.1 + some Android patches (pristine from the android NDK) Mike _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
