Зависимость от порядка инициализации и человеческий фактор

Представитель надолго задумался и разразился тирадой, что неизвестно на что это повлияет и надо понять причину...

хехе, попросите заказчика показать документ или указать программное решение на котором основывается его уверенность о порядке инициализации модулей

Предложил создавать этот их «очень нужный глобальный объект» в момент использования...

тут тоже надо поосторожнее, ибо можно поймать «феникса»

Из доводов разве что тупая принципиальность и невосприятие чужих мнений. Слабоумие, короче.

Он прав,что сомневается. Так делать, конечно, можно, но что, если ты сбацаешь циклическую зависимость? Особенно такую, которая не всегда замыкается. Создание объектов «на лету» не решает автоматически все проблемы. Вот явная инициализация в main() - это надёжно. Я бы так и сделал и денег заодно слупил.

>Так делать, конечно, можно, но что, если ты сбацаешь циклическую зависимость? Особенно такую, которая не всегда замыкается. Создание объектов «на лету» не решает автоматически все проблемы. Вот явная инициализация в main() - это надёжно. Я бы так и сделал и денег заодно слупил.

Цикличность можно в рантайме ловить. Хотя мне тоже больше явная инициализация в main нравится.

У нас в проекте есть
1. enum порядка инициализации (каждый объект, что должен глобально инициализироваться имеет свой элемент) - решает вопрос зависимостей
2. Свой способ инициализации, который явно вызывается первым в каждом main(). И кажись какое-то хитрое объявление глобальных указателей (вместо глобальных объектов), которое их ассоциирует с enum и добавляет в список на инициализацию.

Подробности не помню, т.к. с глобальными объектам дел не особо имею.

>Так делать, конечно, можно, но что, если ты сбацаешь циклическую зависимость?

Ничего не путаете? Этот служебный модуль, где создается глобальный объект, на другие на ссылается. Куча других от него зависит, но он не всегда успевает создать объект. Вариант с main рассматривается. (Он правда больше переделок требует). А тот, который «прав», он пока непонятно чего хочет - «не ясно что с этим делать». Если ничего не делать - проблема вообще не решится. (Тестер через билд жалуется, что свежая сборка не запускается.)

ЕМНИП были еще компиляторозависимые костыли, которые явно задавали порядок инициализации. Но это говно-подход.

>компиляторозависимые костыли

Типа как в XL C++ - прагмы приоритета?

G++ http://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Attributes.html

VC++ http://altdevblogaday.com/2011/07/07/writing-a-pre-main-function-forcing-glob...

Но то чисто для того, чтобы прочитать и больше так не делать.

А... я думал, ты про это http://publib.boulder.ibm.com/infocenter/comphelp/v8v101/index.jsp?topic=%2Fc...

Хотя... смысл тот же.

>Ничего не путаете? Этот служебный модуль, где создается глобальный объект, на другие не ссылается.

(опечатка исправлена)

Сегодня не ссылается, завтра ссылается. Короче, скажи заказчику, что ты всё-всё касаемое того модуля тщательно проверишь. Если он сомневается что ты ничего не упустишь (а он имеет право), либо смотрит в будущее и настаивает на большой переделке - ну так честно скажи, что это больше работы, дольше и дороже. Ну и ткни его строкой из документации компилятора о том, что порядок инициализации переменных разных модулей не определён.

Ну и ткни его строкой из документации компилятора о том, что порядок инициализации переменных разных модулей не определён.

С этого надо начать, а дальше уже предлагать свое решение:) Ну или даже вести его к нему, чтобы он думал, что это его решение.