Порядок инициализации статических переменных

Как вы говорите, порядок в разных единицах компиляции не определен.

В одной и той же единице компиляции порядок четко определен: тот же порядок, что и определение.

Это потому, что это решается не на уровне языка, а на уровне компоновщика. Так что вам действительно нужно проверить документацию по компоновщику. Хотя я действительно сомневаюсь, что это поможет хоть как-то.

Для gcc: проверьте ld

Я обнаружил, что даже изменение порядка связываемых файлов объектов может изменить порядок инициализации. Таким образом, вам нужно беспокоиться не только о компоновщике, но и о том, как компоновщик вызывается вашей системой сборки. Даже попытаться решить проблему практически не срабатывает.

Обычно это проблема только при инициализации глобальных объектов, которые ссылаются друг на друга во время своей собственной инициализации (поэтому влияет только на объекты с конструкторами).

Есть способы обойти эту проблему.

• Ленивая инициализация.
• Счетчик Шварца
• Поместите все сложные глобальные переменные в одну единицу компиляции.

• Примечание 1: глобальные переменные:
  Свободно используется для обозначения статических переменных продолжительности хранения, которые потенциально инициализируются до main().
• Примечание 2: потенциально
  В общем случае мы ожидаем, что статические переменные продолжительности хранения будут инициализированы перед main, но компилятору разрешено отложить инициализацию в некоторых ситуациях (правила сложны, подробности см. В стандарте).

Я ожидаю, что порядок конструктора между модулями в основном зависит от того, в каком порядке вы передаете объекты компоновщику.

Однако GCC позволяет вам используйте init_priority, чтобы явно указать порядок для глобальных операторов:

class Thingy
{
public:
    Thingy(char*p) {printf(p);}
};

Thingy a("A");
Thingy b("B");
Thingy c("C");

выводит "ABC", как и следовало ожидать, но

Thingy a __attribute__((init_priority(300))) ("A");
Thingy b __attribute__((init_priority(200))) ("B");
Thingy c __attribute__((init_priority(400))) ("C");

выводит «BAC».

В дополнение к комментариям Мартина, исходящим из опыта работы с C, я всегда думаю о статических переменных как о части исполняемого файла программы, включенном и выделенном пространстве в сегменте данных. Таким образом, статические переменные можно рассматривать как инициализируемые при загрузке программы перед выполнением любого кода. Точный порядок, в котором это происходит, можно определить, посмотрев на сегмент данных файла карты, выводимый компоновщиком, но для большинства целей и задач инициализация выполняется одновременно.

Обновлено: в зависимости от порядка построения статические объекты могут быть непереносимыми, и, вероятно, их следует избегать.

http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.12 - эта ссылка перемещается. этот один более стабилен, но вам придется поискать его.

edit: osgx предоставил лучший связь.

Если вы действительно хотите знать окончательный порядок, я бы порекомендовал вам создать класс, конструктор которого регистрирует текущую метку времени и создает несколько статических экземпляров класса в каждом из ваших файлов cpp, чтобы вы могли знать окончательный порядок инициализации. Обязательно добавьте в конструктор небольшую трудоемкую операцию, чтобы не получить одинаковую отметку времени для каждого файла.

Поскольку вы уже знаете, что не следует полагаться на эту информацию без крайней необходимости, вот она. Мое общее наблюдение по различным цепочкам инструментов (MSVC, gcc / ld, clang / llvm и т. д.) Заключается в том, что порядок, в котором ваши объектные файлы передаются компоновщику, соответствует порядку, в котором они будут инициализированы.

Есть исключения из этого, и я не претендую на все из них, но вот те, с которыми я столкнулся сам:

1) Версии GCC до 4.7 фактически инициализируются в обратном порядке линии связи. Этот билет в GCC - это когда произошло изменение, и оно сломало множество программ, которые зависели от порядка инициализации (включая мою!).

2) В GCC и Clang использование приоритет функции конструктора может изменить порядок инициализации. Обратите внимание, что это применимо только к функциям, которые объявлены как «конструкторы» (т.е. они должны выполняться так же, как и конструктор глобального объекта). Я пробовал использовать такие приоритеты и обнаружил, что даже с наивысшим приоритетом для функции конструктора все конструкторы без приоритета (например, обычные глобальные объекты, функции конструктора без приоритета) будут инициализированы первый. Другими словами, приоритет относится только к другим функциям с приоритетами, но настоящие первоклассные граждане - это те, кто не имеет приоритета. Что еще хуже, это правило фактически противоположно в GCC до 4.7 из-за пункта (1) выше.

3) В Windows есть очень удобная и полезная функция точки входа с разделяемой библиотекой (DLL) под названием DllMain (), которая, если она определена, будет запускаться с параметром «fdwReason», равным DLL_PROCESS_ATTACH, непосредственно после инициализации всех глобальных данных и до - у приложения-потребителя есть возможность вызывать любые функции библиотеки DLL. В некоторых случаях это чрезвычайно полезно, и поведение не является абсолютно аналогично этому на других платформах с GCC или Clang с C или C++. Самое близкое, что вы найдете, - это создание функции-конструктора с приоритетом (см. Пункт (2) выше), что абсолютно не одно и то же и не будет работать во многих случаях использования, для которых работает DllMain ().

4) Если вы используете CMake для создания ваших систем сборки, что я часто делаю, я обнаружил, что порядок исходных файлов ввода будет порядком их результирующих объектных файлов, переданных компоновщику. Однако часто ваше приложение / DLL также связывается с другими библиотеками, и в этом случае эти библиотеки будут в строке ссылки после ваших исходных файлов ввода. Если вы хотите, чтобы один из ваших глобальных объектов был инициализируемым самый первый, то вам повезло, и вы можете поместить исходный файл, содержащий этот объект, первым в списке исходных файлов. Однако, если вы хотите, чтобы один из них был инициализируемым самый последний (который может эффективно воспроизводить поведение DllMain ()!), Вы можете вызвать add_library () с этим одним исходным файлом для создания статической библиотеки и добавить полученный результат. статическая библиотека в качестве самой последней зависимости ссылки в вашем вызове target_link_libraries () для вашего приложения / DLL. Будьте осторожны, так как ваш глобальный объект может быть оптимизирован в этом случае, и вы можете использовать флаг - весь архив, чтобы заставить компоновщик не удалять неиспользуемые символы для этого конкретного крошечного архивного файла.

Заключительный совет

Чтобы точно узнать конечный порядок инициализации вашего связанного приложения / разделяемой библиотеки, передайте --print-map в ld linker и grep для .init_array (или в GCC до 4.7, grep для .ctors). Каждый глобальный конструктор будет напечатан в том порядке, в котором он будет инициализирован, и помните, что порядок обратный в GCC до 4.7 (см. Пункт (1) выше).

Мотивирующим фактором для написания этого ответа является то, что мне нужно было знать эту информацию, у меня не было другого выбора, кроме как полагаться на порядок инициализации, и я нашел только редкие фрагменты этой информации в других сообщениях SO и интернет-форумах. Большая часть этого была изучена путем множества экспериментов, и я надеюсь, что это сэкономит некоторым людям время на это!

Надежным решением является использование функции получения, которая возвращает ссылку на статическую переменную. Ниже показан простой пример, а сложный вариант - в нашем Промежуточное ПО контроллера SDG.

// Foo.h
class Foo {
 public:
  Foo() {}

  static bool insertIntoBar(int number);

 private:
  static std::vector<int>& getBar();
};

// Foo.cpp
std::vector<int>& Foo::getBar() {
  static std::vector<int> bar;
  return bar;
}

bool Foo::insertIntoBar(int number) {
  getBar().push_back(number);
  return true;
}

// A.h
class A {
 public:
  A() {}

 private:
  static bool a1;
};

// A.cpp
bool A::a1 = Foo::insertIntoBar(22);

Инициализация будет с единственной статической переменной-членом bool A::a1. Тогда это вызовет Foo::insertIntoBar(22). Затем это вызовет Foo::getBar(), в котором инициализация статической переменной std::vector<int> будет происходить перед возвратом ссылки на инициализированный объект.

Если бы static std::vector<int> bar был помещен непосредственно как переменная-член Foo class, была бы вероятность, в зависимости от порядка именования исходных файлов, что bar будет инициализирован после вызова insertIntoBar(), что приведет к сбою программы.

Если несколько статических переменных-членов будут вызывать insertIntoBar() во время их инициализации, порядок не будет зависеть от имен исходных файлов, то есть случайный, но std::vector<int> будет гарантированно инициализирован до того, как в него будут вставлены какие-либо значения.