CODEWITHSUNDEEP
c++g++compiler-warnings
Peeter Joot
Peeter Joot

Reputation: 8260

What's the point of g++ -Wreorder?

The g++ -Wall option includes -Wreorder. What this option does is described below. It is not obvious to me why somebody would care (especially enough to turn this on by default in -Wall).

-Wreorder (C++ only)
  Warn when the order of member initializers given in the code does not
  match the order in which they must be executed.  For instance:

    struct A {
      int i;
      int j;
      A(): j (0), i (1) { }
    };

  The compiler will rearrange the member initializers for i and j to
  match the declaration order of the members, emit-ting a warning to that
  effect.  This warning is enabled by -Wall.

Upvotes: 186

Views: 72721

Answers (6)

Mark Ransom
Mark Ransom

Reputation: 308462

Lots of good answers already, but there's one thing missing - why is the initialization order the way it is?

The order of initialization of class members is not the order that initializers are listed in the constructor, it's the order they're declared in the class itself. The reason why is a bit subtle.

C++ guarantees that the order of destruction will be the opposite of the order of construction for member variables. Since a class can have multiple constructors with different initializer lists, the destructor would need to know that order which would be a big bookkeeping problem and introduce unnecessary overhead. The solution is to force every constructor to use the same order of initialization for members so that the destruction order can be fixed as well.

Since you can't use the initializer order, the only choice is to use the declaration order.

While it is perfectly legal for C++ to initialize the variables in a different order than the initializer list, it's a non-intuitive source of possible bugs. The warning lets you know to look for those bugs, or to reorder your initializer list to reflect reality.

Upvotes: 1

gkb0986
gkb0986

Reputation: 3219

Other answers have provided some good examples that justify the option for a warning. I thought I'd provide some historical context. The creator of C++, Bjarne Stroustrup, explains in his book The C++ programming language (3rd edition, Page 259):

The members’ constructors are called before the body of the containing class’ own constructor is executed. The constructors are called in the order in which they are declared in the class rather than the order in which they appear in the initializer list. To avoid confusion, it is best to specify the initializers in declaration order. The member destructors are called in the reverse order of construction.

Upvotes: 30

Stack Overflow is garbage
Stack Overflow is garbage

Reputation: 248199

The warning exists because if you just read the constructor, it looks like j is getting initialized before i. This becomes a problem if one is used to initialize the other, as in

struct A {
  int i;
  int j;
  A(): j (0), i (this->j) { }
};

When you just look at the constructor, this looks safe. But in reality, j has not yet been initialized at the point where it is used to initialize i, and so the code won't work as expected. Hence the warning.

Upvotes: 8

Steve Jessop
Steve Jessop

Reputation: 279355

The problem is that somebody might see the list of member initialisers in the constructor, and think that they're executed in that order (j first, then i). They are not, they are executed in the order the members are defined in the class.

Suppose you wrote A(): j(0), i(j) {}. Somebody might read that, and think that i ends up with the value 0. It doesn't, because you initialised it with j, which contains junk because it has not itself been initialised.

The warning reminds you to write A(): i(j), j(0) {}, which hopefully looks a lot more fishy.

Upvotes: 59

Pavel Minaev
Pavel Minaev

Reputation: 101615

This can bite you if your initializers have side effects. Consider:

int foo() {
    puts("foo");
    return 1;
}

int bar() {
    puts("bar");
    return 2;
}

struct baz {
    int x, y;
    baz() : y(foo()), x(bar()) {}
};

The above will print "bar" then "foo", even though intuitively one would assume that order is as written in the initializer list.

Alternatively, if x and y are of some user-defined type with a constructor, that constructor may also have side effects, with the same non-obvious result.

It can also manifest itself when initializer for one member references another member.

Upvotes: 13

int3
int3

Reputation: 13201

Consider:

struct A {
    int i;
    int j;
    A() : j(0), i(j) { }
};

Now i is initialized to some unknown value, not zero.

Alternatively, the initialization of i may have some side effects for which the order is important. E.g.

A(int n) : j(n++), i(n++) { }

Upvotes: 308

Related Questions