Using C++ in Mozilla code

C++ language features

Mozilla code only uses a subset of C++. Runtime type information (RTTI) is disabled, as it tends to cause a very large increase in codesize. This means that dynamic_cast, typeid() and <typeinfo> cannot be used in Mozilla code. Also disabled are exceptions; do not use try/catch or throw any exceptions. Libraries that throw exceptions may be used if you are willing to have the throw instead be treated as an abort.

  • As of Mozilla 25, C++11 mode is required to build Mozilla.
  • As of Mozilla 48, gcc 4.8 is required on all platforms.
  • As of Mozilla 50, MSVC 2015 Update 3 is required on Windows.
  • As of Mozilla 53, gcc 4.9 is required on all platforms.
  • As of Mozilla 61, MSVC 2017.6 (aka 15.6) is required on Windows
  • As of Mozilla 61, gcc 6.1 is required on all platforms.

This means that C++11, and some C++14 features, can be used where supported on all platforms. The list of acceptable features is given below:

  MSVC GCC Clang  
Current minimal requirement 2017.6 6.1 3.6  
Feature MSVC GCC Clang Can be used in code
type_t && 2010 4.3 2.9 Yes (see notes)
ref qualifiers on methods 2015 4.8.1 2.9 Yes
member initializers 2013 4.7 3.0 Yes
variadic templates 2013 4.3 2.9 Yes
Initializer lists 2013 4.4 3.1 Yes
static_assert 2010 4.3 2.9 Yes
auto 2010 4.4 2.9 Yes
lambdas 2010 4.5 3.1 Yes
decltype 2010 4.3 2.9 Yes
Foo<Bar<T>> 2010 4.3 2.9 Yes
auto func() -> int 2010 4.4 3.1 Yes
Templated aliasing 2013 4.7 3.0 Yes
nullptr 2010 4.6 3.0 Yes, but use decltype(nullptr) instead of std::nullptr_t.
enum foo : int16_t {}; 2008 4.4 2.9 Yes
enum class foo {}; 2012 4.4 2.9 Yes
enum foo; 2012 4.6 3.1 Yes
[[attributes]] 2015 4.8 3.3 No (see notes)
constexpr 2015 4.6 3.1 Yes
alignas 2015 4.8 3.3 Yes
alignof 2015 4.8 3.3 Yes, but see notes ; only clang 3.6 claims __has_feature(cxx_alignof)
Delegated constructors 2013 4.7 3.0 Yes
Inherited constructors 2015 4.8 3.3 Yes
explicit operator bool() 2013 4.5 3.0 Yes
char16_t/u"string" 2015 4.4 3.0 Yes
R"(string)" 2013 4.5 3.0 Yes
operator""() 2015 4.7 3.1 Yes
=delete 2013 4.4 2.9 Yes
=default 2013 4.4 3.0 Yes
unrestricted unions 2015 4.6 3.1 Yes
for (auto x : vec) 2012 4.6 3.0 Yes (be careful about the type of the iterator)
override/final 2012 4.7 3.0 Yes
thread_local 2015 4.8 3.3 No (see notes)
function template default arguments 2013 4.3 2.9 Yes
local structs as template parameters 2010 4.5 2.9 Yes
extended friend declarations 2010 4.7 2.9 Yes
0b100 (C++14) 2015 4.9 2.9 Yes
Tweaks to some C++ contextual conversions (C++14) 2013 4.9 3.4 Yes
Return type deduction (C++14) 2015 4.9 3.4 Yes (but only in template code when you would have used decltype(complex-expression))
Generic lambdas (C++14) 2015 4.9 3.4 Yes
Initialized lambda captures (C++14) 2015 4.9 3.4 Yes
Digit separator (C++14) 2015 4.9 3.4 Yes
Variable templates (C++14) 2015u2 5.0 3.4 No
Relaxed constexpr (C++14) 2017 5.0 3.4 Yes
Aggregate member initialization (C++14) 2017 5.0 3.3 No
Clarifying memory allocation (C++14) 2017 5.0 3.4 Yes
[[deprecated]] attribute (C++14) 2015 4.9 3.4 No
Sized deallocation (C++14) 2015 5.0 3.4 No (see notes for clang)
Concepts (Concepts TS) 6.0 No
Inline variables (C++17) 7.0 3.9 No
constexpr_if (C++17) 2017.3 7.0 3.9 No
constexpr lambdas (C++17) 2017.3 No
Structured bindings (C++17) 2017.3 7.0 4.0 No
#pragma once Yes 3.4 Yes Not until we normalize headers
Source code information capture 8.0 No




rvalue references: Implicit move method generation cannot be used.

Attributes: Several common attributes are defined in mozilla/Attributes.h or nscore.h.

Alignment: Some alignment utilities are defined in mozilla/Alignment.h. /!\ MOZ_ALIGNOF and alignof don't have the same semantics. Be careful of what you expect from them.

Thread locals: There is a thread-local variable helper in mozilla/ThreadLocal.h. In addition, the native thread_local of MSVC2015 may break Windows XP support. See bug 1204752. The native thread_local of clang may break OSX 10.6, too, but support for OSX 10.6 has been retired.

C++14: C++14 is not enabled on compilers that support it.

Clang 3.7 and later require passing -fsized-deallocation to the compiler to activate the sized deallocation feature.

C++ and Mozilla standard libraries

The Mozilla codebase contains within it several subprojects which follow different rules for which libraries can and can't be used it. The rules listed here apply to normal platform code, and assume unrestricted usability of MFBT or XPCOM APIs.

The rest of this section is a draft for expository and exploratory purposes. Do not trust the information listed here.

What follows is a list of standard library components provided by Mozilla or the C++ standard. If an API is not listed here, then it is not permissible to use it in Mozilla code. Deprecated APIs are not listed here. 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.

A list of approved standard library headers is maintained in config/stl-headers.mozbuild.

Data structures

Name Header STL equivalent Notes
nsAutoTArray nsTArray.h   Like nsTArray, but will store a small amount as stack storage
nsAutoTObserverArray nsTObserverArray.h   Like nsTObserverArray, but will store a small amount as stack storage
mozilla::BloomFilter mozilla/BloomFilter.h   Probabilistic set membership (see Wikipedia)
nsClassHashtable nsClassHashtable.h   Adaptation of nsTHashtable, see XPCOM hashtable guide
nsCOMArray nsCOMArray.h   Like nsTArray<nsCOMPtr<T>>
nsDataHashtable nsClassHashtable.h std::unordered_map Adaptation of nsTHashtable, see XPCOM hashtable guide
nsDeque nsDeque.h std::deque  
mozilla::EnumSet mozilla/EnumSet.h   Like std::set, but for enum classes.
nsInterfaceHashtable nsInterfaceHashtable.h std::unordered_map Adaptation of nsTHashtable, see XPCOM hashtable guide
nsJSThingHashtable nsJSThingHashtable.h   Adaptation of nsTHashtable, see XPCOM hashtable guide
mozilla::LinkedList mozilla/LinkedList.h std::list Doubly-linked list
nsRefPtrHashtable nsRefPtrHashtable.h std::unordered_map Adaptation of nsTHashtable, see XPCOM hashtable guide
mozilla::SegmentedVector mozilla/SegmentedVector.h std::deque Doubly-linked list of vector elements
mozilla::SplayTree mozilla/SplayTree.h   Quick access to recently-accessed elements (see Wikipedia)
nsTArray nsTArray.h std::vector  
nsTHashtable nsTHashtable.h std::unordered_map See XPCOM hashtable guide, you probably want a subclass
nsTObserverArray nsTObserverArray.h   Like nsTArray, but iteration is stable even through mutation
nsTPriorityQueue nsTPriorityQueue.h std::priority_queue Unlike the STL class, not a container adapter
mozilla::Vector mozilla/Vector.h std::vector  

Safety utilities

Name Header STL equivalent Notes
mozilla::Array mfbt/Array.h   safe array index
mozilla::AssertedCast mfbt/Casting.h   casts
mozilla::CheckedInt mfbt/CheckedInt.h   avoids overflow
nsCOMPtr xpcom/glue/nsCOMPtr.h std::shared_ptr  
mozilla::EnumeratedArray mfbt/EnumeratedArray.h mozilla::Array  
mozilla::Maybe mfbt/Maybe.h std::optional  
mozilla::RangedPtr mfbt/RangedPtr.h   like mozilla::Span but with two pointers instead of pointer and length
mozilla::RefPtr mfbt/RefPtr.h std::shared_ptr  
nsRefPtr xpcom/base/nsRefPtr.h std::shared_ptr  
mozilla::Span mozilla/Span.h gsl::span, absl::Span, std::string_view, std::u16string_view Rust's slice concept for C++ (without borrow checking)
StaticRefPtr xpcom/base/StaticPtr.h   nsRefPtr w/o static constructor
mozilla::UniquePtr mfbt/UniquePtr.h std::unique_ptr  
mozilla::WeakPtr mfbt/WeakPtr.h std::weak_ptr  
nsWeakPtr xpcom/base/nsWeakPtr.h std::weak_ptr  


See the Mozilla internal string guide for usage of nsAString (our copy-on-write replacement for std::u16string) and nsACString (our copy-on-write replacement for std::string).

Be sure not to introduce further uses of std::wstring, which is not portable! (Some uses exist in the IPC code.)


mozilla::BinarySearch mfbt/BinarySearch.h
mozilla::BitwiseCast mfbt/Casting.h (strict aliasing-safe cast)
mozilla/MathAlgorithms.h (rotate, ctlz, popcount, gcd, abs, lcm)
mozilla::RollingMean mfbt/RollingMean.h ()


mozilla::Atomic mfbt/Atomic.h (replacement for std::atomic)
mozilla::CondVar xpcom/glue/CondVar.h
mozilla::Monitor xpcom/glue/Monitor.h
mozilla::Mutex xpcom/glue/Mutex.h
mozilla::ReentrantMonitor xpcom/glue/ReentrantMonitor.h
mozilla::StaticMutex xpcom/base/StaticMutex.h


mozilla::AlignedStorage mfbt/Alignment.h (replacement for std::aligned_storage)
mozilla::MaybeOneOf mfbt/MaybeOneOf.h (~mozilla::Maybe<union {T1, T2}>)
mozilla::Pair mfbt/Pair.h (~= std::tuple<T1, T2> -- minimal space!)
mozilla::TimeStamp xpcom/ds/TimeStamp.h (~= std::chrono::time_point)

mozilla/HashFunctions.h (~= std::hash)
mozilla/Move.h (std::move, std::swp, std::Forward)
mozilla/PodOperations.h (C++ versions of memset, memcpy, etc.)
mozilla/TypeTraits.h (replacement for <type_traits>)

Further C++ rules

Don't use static constructors

(You probably shouldn't be using global variables to begin with. Quite apart from the weighty software-engineering arguments against them, globals affect startup time! But sometimes we have to do ugly things.)

Non-portable example:

FooBarClass static_object(87, 92);

  if (static_object.count > 15) {

Once upon a time, there were compiler bugs that could result in constructors not being called for global objects. Those bugs are probably long gone by now, but even with the feature working correctly, there are so many problems with correctly ordering C++ constructors that it's easier to just have an init function:

static FooBarClass* static_object;

  if (!static_object)
    static_object =
      new FooBarClass(87, 92);
  return static_object;

  if (getStaticObject()->count > 15) {

Don't use exceptions

See the introduction to the "C++ language features" section at the start of this document.

Don't use Run-time Type Information

See the introduction to the "C++ language features" section at the start of this document.

If you need runtime typing, you can achieve a similar result by adding a classOf() virtual member function to the base class of your hierarchy and overriding that member function in each subclass. If classOf() returns a unique value for each class in the hierarchy, you'll be able to do type comparisons at runtime.

Don't use the C++ standard library (including iostream and locale)

See the section "C++ and Mozilla standard libraries".

Use C++ lambdas, but with care

C++ lambdas are supported across all our compilers now.  Rejoice!  We recommend explicitly listing out the variables that you capture in the lambda, both for documentation purposes, and to double-check that you're only capturing what you expect to capture.

Use namespaces

Namespaces may be used according to the style guidelines in Mozilla Coding Style Guide.

Don't mix varargs and inlines

What? Why are you using varargs to begin with?! Stop that at once!

Make header files compatible with C and C++

Non-portable example:

int existingCfunction(char*);
int anotherExistingCfunction(char*);

/* oldCfile.c */
#include "oldCheader.h"

// new file.cpp
extern "C" {
#include "oldCheader.h"

If you make new header files with exposed C interfaces, make the header files work correctly when they are included by both C and C++ files.

(If you need to include a C header in new C++ files, that should just work. If not, it's the C header maintainer's fault, so fix the header if you can, and if not, whatever hack you come up with will probably be fine.)

Portable example:

/* oldCheader.h*/
int existingCfunction(char*);
int anotherExistingCfunction(char*);

/* oldCfile.c */
#include "oldCheader.h"

// new file.cpp
#include "oldCheader.h"

There are number of reasons for doing this, other than just good style. For one thing, you are making life easier for everyone else, doing the work in one common place (the header file) instead of all the C++ files that include it. Also, by making the C header safe for C++, you document that "hey, this file is now being included in C++". That's a good thing. You also avoid a big portability nightmare that is nasty to fix...

Use override on subclass virtual member functions

The override keyword is supported in C++11 and in all our supported compilers, and it catches bugs.

Always declare a copy constructor and assignment operator

Many classes shouldn't be copied or assigned. If you're writing one of these, the way to enforce your policy is to declare a deleted copy constructor as private and not supply a definition. While you're at it, do the same for the assignment operator used for assignment of objects of the same class. Example:

class Foo {
    Foo(const Foo& x) = delete;
    Foo& operator=(const Foo& x) = delete;

Any code that implicitly calls the copy constructor will hit a compile-time error. That way nothing happens in the dark. When a user's code won't compile, they'll see that they were passing by value, when they meant to pass by reference (oops).

Be careful of overloaded methods with like signatures

It's best to avoid overloading methods when the type signature of the methods differs only by one "abstract" type (e.g. PR_Int32 or int32). What you will find as you move that code to different platforms, is suddenly on the Foo2000 compiler your overloaded methods will have the same type-signature.

Type scalar constants to avoid unexpected ambiguities

Non-portable code:

class FooClass {
  // having such similar signatures
  // is a bad idea in the first place.
  void doit(long);
  void doit(short);

B::foo(FooClass* xyz)

Be sure to type your scalar constants, e.g., uint32_t(10) or 10L. Otherwise, you can produce ambiguous function calls which potentially could resolve to multiple methods, particularly if you haven't followed (2) above. Not all of the compilers will flag ambiguous method calls.

Portable code:

class FooClass {
  // having such similar signatures
  // is a bad idea in the first place.
  void doit(long);
  void doit(short);

B::foo(FooClass* xyz)

Use nsCOMPtr in XPCOM code

See the nsCOMPtr User Manual for usage details.

Don't use identifiers that start with an underscore

This rule occasionally surprises people who've been hacking C++ for decades. But it comes directly from the C++ standard!

According to the C++ Standard, Global Names [], paragraph 1:

Certain sets of names and function signatures are always reserved to the implementation:

  • Each name that contains a double underscore (__) or begins with an underscore followed by an uppercase letter (2.11) is reserved to the implementation for any use.
  • Each name that begins with an underscore is reserved to the implementation for use as a name in the global namespace.

Stuff that is good to do for C or C++

Avoid conditional #includes when possible

Don't write an #include inside an #ifdef if you could instead put it outside. Unconditional includes are better because they make the compilation more similar across all platforms and configurations, so you're less likely to cause stupid compiler errors on someone else's favorite platform that you never use.

Bad code example:

#include <stdlib.h>   // <--- don't do this
#include "jpeg4e9.h"  // <--- only do this if the header really might not be there

Of course when you're including different system files for different machines, you don't have much choice. That's different.

Every .cpp source file should have a unique name

Every object file linked into libxul needs to have a unique name. Avoid generic names like nsModule.cpp and instead use nsPlacesModule.cpp.

Turn on warnings for your compiler, and then write warning free code

What generates a warning on one platform will generate errors on another. Turn warnings on. Write warning-free code. It's good for you. Treat warnings as errors by adding ac_add_options --enable-warnings-as-errors to your mozconfig file.

Use the same type for all bitfields in a struct or class

Some compilers (even recent ones like MSVC 2013) do not pack the bits when different bitfields are given different types. For example, the following struct might have a size of 8 bytes, even though it would fit in 1:

struct {
  char ch : 1;
  int i : 1;

Don't use an enum type for a bitfield

The classic example of this is using PRBool for a boolean bitfield. Don't do that. PRBool is a signed integer type, so the bitfield's value when set will be -1 instead of +1, which---I know, crazy, right? The things C++ hackers used to have to put up with...

You shouldn't be using PRBool anyway. Use bool. Bitfields of type bool are fine.

Enums are signed on some platforms (in some configurations) and unsigned on others and therefore unsuitable for writing portable code when every bit counts, even if they happen to work on your system.

Document Tags and Contributors

 Last updated by: jdashg,