У чому сенс g ++ -порядку?

Параметр g ++ -Wall включає -порядок. Що робить цей варіант, описано нижче. Мені не очевидно, чому хтось би переймався (особливо достатньо, щоб це було включено за замовчуванням у -Wall).

-Заказ (лише C ++)
  Попередити, коли порядок ініціалізаторів членів, вказаний у коді, не відповідає
  відповідають порядку, в якому вони повинні бути виконані. Наприклад:

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

  Компілятор переставить ініціалізатори членів для i та j до
  відповідати порядку декларації членів, видаючи попередження цьому
  ефект. Це попередження увімкнено функцією -Wall.

Поміркуйте:

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

Тепер iініціалізовано до якогось невідомого значення, а не до нуля.

Альтернативно, ініціалізація iможе мати деякі побічні ефекти, для яких важливий порядок. Напр

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

Проблема полягає в тому, що хтось може побачити список ініціалізаторів членів у конструкторі і подумати, що вони виконані в такому порядку (j спочатку, потім i). Вони не є, вони виконуються в порядку, визначеному членами в класі.

Припустимо, ви написали A(): j(0), i(j) {}. Хтось може прочитати це і подумати, що я закінчується значенням 0. Це не так, тому що ви ініціалізували його з j, яке містить непотріб, тому що він сам не був ініціалізований.

Попередження нагадує вам написати A(): i(j), j(0) {}, що, сподіваємось, виглядає набагато рибніше.

Інші відповіді надають кілька хороших прикладів, які виправдовують варіант попередження. Я думав, що надаю історичний контекст. Творець C ++, Bjarne Stroustrup, пояснює у своїй книзі Мова програмування C ++ (3-е видання, Сторінка 259):

Конструктори членів викликаються перед виконанням власного конструктора тіла класу, що містить. Конструктори викликаються в тому порядку, в якому вони оголошені в класі, а не в тому порядку, в якому вони відображаються в списку ініціалізатора. Щоб уникнути плутанини, найкраще вказати ініціалізатори в порядку декларування. Деструктори-члени називаються у зворотному порядку побудови.

Це може укусити вас, якщо у ваших ініціалізаторів є побічні ефекти. Поміркуйте:

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

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

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

Вище буде надруковано "bar", а потім "foo", хоча інтуїтивно можна вважати, що порядок такий, як записано у списку ініціалізатора.

Як варіант, якщо xіy має певний визначений користувачем тип з конструктором, цей конструктор також може мати побічні ефекти, з тим же неочевидним результатом.

Це може також проявлятися, коли ініціалізатор для одного члена посилається на іншого члена.

Попередження існує, тому що якщо ви просто прочитали конструктор, воно, схоже j, ініціалізується раніше i. Це стає проблемою, якщо один використовується для ініціалізації іншого, як у

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

Коли ви просто дивитесь на конструктор, це виглядає безпечно. Але насправді jвона ще не була ініціалізована в точці, де вона використовується для ініціалізації i, і тому код не буде працювати, як очікувалося. Звідси попередження.