On 7/31/2013 3:25 AM, Brian Smith wrote:
On Wed, Jul 31, 2013 at 6:53 AM, Joshua Cranmer 🐧 <pidgeo...@gmail.com>wrote:
On 7/30/2013 10:39 PM, Brian Smith wrote:
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.
Basically, I'm proposing that we add std::unique_ptr, std::move,
std::forward, and some nulllptr polyfill to STLPort with the intention that
we can assume these features work. That is, if some (compiler, standard
library) combination doesn't have these features then it would be an
unsupported combination.
More generally, nobody should be reasonably expected to write code that
builds with any combination that isn't used on mozilla-central's TBPL. So,
(clang, MSVC) is not really something to consider, for example.
clang + MSVC is not a combination I expect us to support anytime soon.
My main intent was to point out that library polyfilling is much harder
than it is for compiler features. Look at the mess that is determining
when we can use <atomic>.
We should be more aggressive in requiring newer compiler versions whenever
practical, and we should choose to support as few compiler/library
combinations as we can get away with. That way we can use as many C++11/14
features (not just library features, but also language features) as
possible without any portability shims, and we can save developer effort by
avoiding adding code to MFBT that duplicates standard library
functionality. The only time we should be requiring less than the latest
version of any compiler on any platform is when that compiler is the
compiler used for official builds on that platform and the latest version
doesn't work well enough.
I disagree. My baseline recommendation is that we should support the
newest compiler present on a stable distribution (I assume Debian stable
for a given ESR. This amounts to gcc 4.7 in practice on Linux at the
moment. Windows and OS X compiler support is harder to gauge, but I
think we should at least support the last two released versions of a
compiler at any given time. Clang releases roughly every 6 months and
MSVC is moving to a roughly yearly release schedule. This means that we
should generally expect to support any compiler version released in the
last two or three years.
Anyway, it would be easier to swallow the dependency on MFBT if it wasn't
so large (over 100 files now), if it tried to be (just) a polyfill for
missing standard library features, and if it could easily be used
independently of the Gecko build system. But, none of those constraints is
reasonable to place on MFBT, so that means MFBT isn't a good choice for
most things that need to also be able to be built independently of Gecko.
I think we need a single polyfill for C++ standard library features.
NSPR was that for C and POSIX, but as we get increasingly powerful
things in standard C++, it makes less sense to be using it for base
platform support (asynchronous I/O and sockets are planned for a
networking TS). I've been assuming that this C++ polyfill is MFBT, but
it may make sense to separate the C++ polyfill (+ arguably some stuff
like Assertions.h/Attributes.h) from the "assorted other ADT stuff"
(like BloomFilter, SplayTree).
--
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
