On 7/30/2013 10:39 PM, Brian Smith wrote:
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).
One thing I want to point out is that, while compiler features are
relatively easy to select based on catching macro versions, the C++
standard library is not, since compiler versions don't necessarily
correlate with standard library versions. We basically support 4
standard libraries (MSVC, libstdc++, stlport, and libc++); under the
right conditions, clang could be using any of those four versions. This
means it's hard to tell when #include'ing a standard header will give us
the feature or not. The C++ committee is actively working on a consensus
solution to this issue, but it would not be rolled out to production
compilers until 2014 at the earliest.
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.
One of the goals of MFBT is to bridge over the varying support of
C++11/C++14 in current compilers, although it also includes useful data
structures that are not necessary for C++ compatibility. Since we have
an increasing number of semi-autonomous C++ projects in mozilla-central,
it makes sense that we should have a smallish (header-only, if
possible?) compatibility bridge library, but if that is not MFBT, then I
don't know what it is or should be. As it stands, we have a fair amount
of duplication right now.
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.
I'm actually planning on discussing this in more detail in a newsgroup
post I'm working on right now.
--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
