Есть

//file1.cpp
A a;
B b;
//file2.cpp
A a1;
B b1;

Допустим, порядок инициализации был такой : a, b (понятно, что в пределах одной единицы трансляции все не так уж сложно); a1, b1.
b1 разрушится перед a1, b — перед a. Есть ли гарантия, что при описанном порядке вызова конструкторов, деструкторы вызовутся так b1, a1, b, a.

Здравствуйте, Аноним, Вы писали:

А>Есть
А>

А>//file1.cpp
А>A a;
А>B b;
А>//file2.cpp
А>A a1;
А>B b1;
А>

А>Допустим, порядок инициализации был такой : a, b (понятно, что в пределах одной единицы трансляции все не так уж сложно); a1, b1.
А>b1 разрушится перед a1, b — перед a. Есть ли гарантия, что при описанном порядке вызова конструкторов, деструкторы вызовутся так b1, a1, b, a.
Ну так взять и проверить — в конструкторы — деструкторы пропиши cout — по крайней мере на конкретном компиляторе будешь знать, в каколм порядке.

Здравствуйте, Аноним, Вы писали:

А>Есть ли гарантия, что при описанном порядке вызова конструкторов, деструкторы вызовутся так b1, a1, b, a.

Да, есть.
Объекты со static storag duration разрушаются в порядке, обратном порядку создания:
3.6.3 Termination

1 Destructors (12.4) for initialized objects of static storage duration (declared at block
scope or at namespace scope) are called as a result of returning from main and as a result of
calling exit (18.3). These objects are destroyed in the reverse order of the completion of their
constructor or of the completion of their dynamic initialization. If an object is initialized
statically, the object is destroyed in the same order as if the object was dynamically initialized.
For an object of array or class type, all subobjects of that object are destroyed before any local
object with static storage duration initialized during the construction of the subobjects is
destroyed.

Плевать на конкретный компилятор, у меня их штук 5 и постоянно помнить все их глюки

В стандарте написано, что статические объекты разрушаются в обратном порядке, порядку создания, так что, ответ, похоже, ДА.

Здравствуйте, Аноним, Вы писали:

А>Плевать на конкретный компилятор, у меня их штук 5 и постоянно помнить все их глюки

А>В стандарте написано, что статические объекты разрушаются в обратном порядке, порядку создания, так что, ответ, похоже, ДА.
Это все хорошо и правильно. Но
"компилятор всегда прав". Если компилятор не прав — смотри пункт 1". В каждой шутке, конечно есть доля истины, но здесь она достигает процентов 99 примерно

Здравствуйте, Аноним, Вы писали:

А>Допустим, порядок инициализации был такой : a, b (понятно, что в пределах одной единицы трансляции все не так уж сложно); a1, b1.
А>b1 разрушится перед a1, b — перед a. Есть ли гарантия, что при описанном порядке вызова конструкторов, деструкторы вызовутся так b1, a1, b, a.

Гарантия есть. Стандарт: 3.6.3.

Здравствуйте, LaptevVV, Вы писали:

А>>В стандарте написано, что статические объекты разрушаются в обратном порядке, порядку создания, так что, ответ, похоже, ДА.
LVV>Это все хорошо и правильно. Но
LVV> "компилятор всегда прав". Если компилятор не прав — смотри пункт 1". В каждой шутке, конечно есть доля истины, но здесь она достигает процентов 99 примерно

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

Типовые грабли — это вот:

struct Goodbye
{
  string* msg;

  Goodbye(string* s) : msg(s) {}
  ~Goodbye() { cout << *msg; }

  void operator=(string* s) { msg = s; }
};

string msg1 = "okay";
Goodbye goodbye = &msg1;
string msg2 = "oops";

main()
{
  goodbye = msg2;
}

Здравствуйте, Bell, Вы писали:

B>Здравствуйте, Аноним, Вы писали:

А>>Есть ли гарантия, что при описанном порядке вызова конструкторов, деструкторы вызовутся так b1, a1, b, a.

B>Да, есть.
B>Объекты со static storag duration разрушаются в порядке, обратном порядку создания:

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

Здравствуйте, Аноним, Вы писали:

А>Еще бы порядок создания знать, особенно для объектов в разных модулях, то было бы вообще замечательно...

Порядок создания, увы, не определен.

Хотя я сильно сомневаюсь, чтобы это сильно помогло. Скорее наоборот.

Здравствуйте, Bell, Вы писали:

B>Здравствуйте, Аноним, Вы писали:

А>>Еще бы порядок создания знать, особенно для объектов в разных модулях, то было бы вообще замечательно...

B>Порядок создания, увы, не определен.

B>Хотя я сильно сомневаюсь, чтобы это сильно помогло. Скорее наоборот.
Я к тому, что зарекаться на какой-то особый порядок создания/удаления статических
объетов в общем-то не безопасно.
Были у меня как-то 2 статических сингелтона, зависящих друг от друга.
На VC6.0 все работало прекрасно (повезло), а вот на навой студии порядок создания
(а значить и удаления) "слегка" изменился. Пришлось избавляться от этой зависимости...

Здравствуйте, Аноним, Вы писали:

B>>Хотя я сильно сомневаюсь, чтобы это сильно помогло. Скорее наоборот.
А>Я к тому, что зарекаться на какой-то особый порядок создания/удаления статических
А>объетов в общем-то не безопасно.

Я склонен с этим согласиться

мне кажется, что такая "поломка" даже новой студии не требует, достаточно что-нить поменять/перекомпилить/перекомпоновать и уже беда.

Здравствуйте, Lorenzo_LAMAS, Вы писали:

L_L>мне кажется, что такая "поломка" даже новой студии не требует, достаточно что-нить поменять/перекомпилить/перекомпоновать и уже беда.

Согласен...

Здравствуйте, Кодт, Вы писали:

К>Оставшийся 1%, достигающий в военное время 4.14, лежит на объектах с затейливыми конструкторами, на статических переменных внутри функций и на динамических библиотеках.

К>Типовые грабли — это вот:
К>

К>struct Goodbye
К>{
К>  string* msg;

К>  Goodbye(string* s) : msg(s) {}
К>  ~Goodbye() { cout << *msg; }

К>  void operator=(string* s) { msg = s; }
К>};

К>string msg1 = "okay";
К>Goodbye goodbye = &msg1;
К>string msg2 = "oops";

К>main()
К>{
К>  goodbye = msg2;
К>}
К>

Ага, знаем, проходили. И даже студентам рассказывали.

> мне кажется, что такая "поломка" даже новой студии не требует, достаточно что-нить поменять/перекомпилить/перекомпоновать и уже беда.

для "таких" поломок вроде как придумали Phenix синглтон