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. > 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. > 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. 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. Cheers, Brian _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
