On Wed, Jul 31, 2013 at 4:50 AM, Ehsan Akhgari <ehsan.akhg...@gmail.com>wrote:
> On Tue, Jul 30, 2013 at 7:40 PM, Brian Smith <br...@briansmith.org>wrote: > >> 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? > Yes: Then we can use std::unique_ptr in parts of Gecko that are intended to be buildable without MFBT (see below). > (Also remember that STLport is an STL implementation, so it is entirely ok > for them to put things into namespace std!) > To be clear, I am not proposing that we add std::move/forward/unique_ptr to MFBT. I am suggesting that we add them to STLPort. We could even eventually upstream them. EDIT: I just saw Mike's post that STLPort upstream already has unique_ptr/move/forward. Perhaps we can backport them into our STLPort tree. FWIW, we have created a new certificate verification library written in C++. One of my goals is to eventually make it so that it can be embedded in server-side software to support things like OCSP stapling, short-lived certificates, and auto-fixing of certificate chains in servers, which are things that make SSL faster and easier to deploy. Basically, the idea is that the server can (pre-)build/verify their certificate chain exactly as Firefox would. There are also some security researchers interested in using a "real" browser's certificate processing logic in studies they are doing. This kind of research directly benefits my work on Gecko and I'm intending to share this library with them so they can use it in their research. For this sub-project, I've been trying to avoid any Gecko (including MFBT) dependencies and I will be cutting down (removing?) the NSPR and NSS dependencies over time. In order to avoid the MFBT dependency, I created my own ScopedPtr class and cviecco added a hack for GCC 4.4's nullptr. We also have been doing the typical hacky/dangerous stuff to deal with a world without std::move()/forward() and without <cstdint>. Now we can use <cstdint> (or at least <stdint.h>?), and I'm eager to fix these "last mile" issues. Besides that, in general I'd like to continue making Gecko's code less foreign to C++ coders. In particular, I'd like to get rid of nsAutoPtr<T> and mozilla::ScopedPtr<T> completely. Cheers, Brian _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
