Working on large codebases often means following well-justified custom conventions. Not only one must learn have a really good grasp of various languages, programmatically enforced styles, and also “cultural conventions” that, although allowed by a style guide, often won’t make it past code review. For example, in Gecko, using the auto keyword is generally frowned upon because auto hides information from reviewers (but shouldn’t be an issue in an IDE, where Intellisense can statically deduce the type).
Further, large projects tend to build up their own “flavor” of C++… at Mozilla at least engineers would colloquially refer to C++ as “Mozilla C++”. See the “Using C++ in Mozilla code” guide, which states:
“In general, prefer Mozilla variants of data structures to standard C++ ones, even when permitted to use the latter, since Mozilla variants tend to have features not found in the standard library (e.g., memory size tracking) or have more controllable performance characteristics.”
In practice it means you are discouraged from using and learning standard language facilities in favor of purpose build classes. As a quick example, you would use “nsDataHashtable” in favor of std::unordered_map. See the table at “C++ and Mozilla standard Libraries” for more examples.
Although justified, the tradeoff with not using “std::”, as a developer, is that you lose the ability to learn and practice using “std::” classes, templates, and other goodies. This is detrimental when jumping to other projects, because it means having to relearn how to use standard things.
As a standards engineer, I personally wish that projects like Gecko, that are involved with the standardization of C++, would improve the underlying “std::” classes and facilities. That might not be possible in every case, but I imagine in some cases there would be opportunity for improvements to the underlying implementations and compilers.
At the same time, Mozilla went on to build Rust, so… maybe that was time better spent than fixing C++.