Page History

The member initializer list for a class constructor allows members to be initialized to specified values and for base class constructors to be called with specific arguments. However, the order in which initialization occurs is fixed and does not depend on the order written in the member initializer list. The C++ 2003, Section 12.6.2 "Initializing bases and members", paragraph 5, says:Standard, [class.base.init], paragraph 11 [ISO/IEC 14882-2014], states the following:

In a non-delegating constructor, initialization proceeds Initialization shall proceed in the following order:
— — First, and only for the constructor of the most derived class as described below, virtual base classes shall be are initialized in the in the order they appear on a depth-first left-to-right traversal of the directed acyclic graph of base classes, where “left where “left-to-right” right” is the order of appearance of the base class names classes in the derived class base-specifier-list.
— — Then, direct base classes shall be are initialized in declaration order as they appear in the base-specifier-list list (regardless of the order of the mem-initializers).
— — Then, nonstatic non-static data members shall be are initialized in the order they were declared in the class definition definition (again regardless of the order of the mem-initializers).
— — Finally, the body compound-statement of the constructor body is executed.
[Note: The declaration order is mandated to ensure that base and member subobjects are destroyed in the reverse order of initialization. —end note]

Consequently, the order in which constructor member initializers appear is actually irrelevent, as the in the member initializer list is irrelevant. The order in which they are executed members are initialized, including base class initialization, is determined by external items, such as the declaration order of the class fields. Reordering the initializers has no effect on the code execution, but can confuse programmers and lead to undefined behavior.

Non-Compliant Code Example

member variables or the base class specifier list. Writing member initializers other than in canonical order can result in undefined behavior, such as reading uninitialized memory.

Always write member initializers in a constructor in the canonical order: first, direct base classes in the order in which they appear in the base-specifier-list for the class, then nonstatic data members in the order in which they are declared in the class definition.

Noncompliant Code Example

In this noncompliant code example, the member initializer list for C::C() attempts to initialize someVal first and then to initialize dependsOnSomeVal to a value dependent on someVal. Because the declaration order of the member variables does not match the member initializer order, attempting to read the value of someVal results in an unspecified value being stored into dependsOnSomeVal.

class C {
  int adependsOnSomeVal;
  int bsomeVal;
 
public:
  C(int val) : bsomeVal(3val), adependsOnSomeVal(bsomeVal + 1) {}
};

In class c's default constructor a is initialized before b because a is declared before b in the class body. Consequently a's initialization depends on the unitialized value of b, and so a will likely hold garbage.

Implementation Details

MSVC 2008 compiles this code without warning. It sets c.b to 3, and c.a to -858993459.

G++ 4.3.3 issues a warning regarding the misordered initializers. It sets c.b to 3 and c.a to 32515.

Non-Compliant Code Example

Compliant Solution

This compliant solution changes the declaration order of the class member variables so that the dependency can be ordered properly in the constructor's member initializer list.

class C {
  int someVal;
  int dependsOnSomeVal;
 
public:
  C(int val) : someVal(val), dependsOnSomeVal(someVal + 1) {}
};

It is reasonable for initializers to depend on previously initialized values.

Noncompliant Code Example

In this noncompliant code example, the derived class, D, attempts to initialize the base class, B1, with a value obtained from the base class, B2. However, because B1 is initialized before B2 due to the declaration order in the base class specifier list, the resulting behavior is undefined.This code reorders the initializers correctly:

class CB1 {
  int val;
 
public:
  B1(int a;
  int b; val) : val(val) {}
};

class B2 {
  int otherVal;
 
public:
  CB2(int otherVal) : aotherVal(b+1), b(3) {otherVal) {}
  int get_other_val() const { return otherVal; }
};

This code is still noncompliant, but now the error is obvious, a clearly depends on b despite being initialized first.

Compliant Solution

class D : B1, B2 {
public:
  D(int a) : B2(a), B1(get_other_val()) {}
};

Compliant Solution

This compliant solution initializes both base classes using the same value from the constructor's parameter list instead of relying on the initialization order of the base classesThis code resolves the dependency.

class B1 {
  int val;
 
public:
  B1(int val) : val(val) {}
};

class CB2 {
  int aotherVal;
 
public:
  B2(int b; otherVal) : otherVal(otherVal) {}
};

class D : B1, B2 {
public:
  CD(int a) : B1(a(4), bB2(a-1) {}
};

Exceptions

Risk Assessment

Bibliography

\[[Lockheed Martin 05|AA. Bibliography#Lockheed Martin 05]\] AV Rule 75 Members of the initialization list shall be listed in the order in which they are declared in the class.
\[[ISO/IEC 14882-2003|AA. Bibliography#ISO/IEC 14882-2003]\] Section 12.6.2 "Initializing bases and members"

Automated Detection

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

Bibliography

...

Image Added Image Added Image Added OOP36-CPP. Do not assume that copy constructor invocations will not be elided      13. Object Oriented Programming (OOP)      14. Concurrency (CON)