views:

203

answers:

4

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.
+15  A: 

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++) { }
int3
This should really be the example in the documentation.
Ben S
thanks. With most of our types being POD types with simple initializers this didn't occur to me. Your example is much better than the g++ manual example.
Peeter Joot
A: 

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.

Pavel Minaev
+4  A: 

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.

Steve Jessop
+1  A: 

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.

jalf