Глобальный объект и порядок создания

Они не инициализируются в алфавитном порядке, а порядок инициализации среди единиц перевода не определен, поскольку стандарт ничего не гарантирует по этому поводу.

Почему глобальные переменные — это зло

Глобальных переменных следует избегать по нескольким причинам, но основная причина заключается в том, что они значительно усложняют вашу программу. Например, предположим, что вы изучаете программу и хотите знать, для чего используется переменная с именем g_nValue. Поскольку g_nValue является глобальным, а глобальные значения могут использоваться в любом месте всей программы, вам придется проверять каждую строку каждого отдельного файла! В компьютерной программе с сотнями файлов и миллионами строк кода вы можете себе представить, сколько времени это займет!

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

Почему следует избегать глобальных переменных, когда они не нужны

Нелокальность. Исходный код легче всего понять, когда объем его отдельных элементов ограничен. Глобальные переменные могут быть прочитаны или изменены любой частью программы, что затрудняет запоминание или обдумывание каждого возможного использования.

Нет контроля доступа или проверки ограничений. Глобальная переменная может быть получена или установлена ​​любой частью программы, и любые правила, касающиеся ее использования, могут быть легко нарушены или забыты. (Другими словами, методы доступа get/set, как правило, предпочтительнее, чем прямой доступ к данным, и тем более для глобальных данных.) Кроме того, отсутствие контроля доступа сильно мешает достижению безопасности в ситуациях, когда вы можете захотеть запустить ненадежный код. (например, работа со сторонними плагинами). Неявная связь. Программа со многими глобальными переменными часто имеет тесную связь между некоторыми из этих переменных, а также связь между переменными и функциями. Группировка связанных элементов в связные единицы обычно приводит к улучшению программ.

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

Загрязнение пространства имен. Глобальные имена доступны везде. Вы можете неосознанно в конечном итоге использовать глобальный, когда думаете, что используете локальный (из-за неправильного написания или забывая объявить локальный) или наоборот. Кроме того, если вам когда-либо придется связывать модули с одинаковыми именами глобальных переменных, если вам повезет, вы получите ошибки связывания. Если вам не повезет, компоновщик просто будет рассматривать все случаи использования одного и того же имени как один и тот же объект. Проблемы с выделением памяти. В некоторых средах есть схемы выделения памяти, усложняющие выделение глобальных переменных. Это особенно верно для языков, в которых «конструкторы» имеют побочные эффекты, отличные от выделения (поскольку в этом случае вы можете выразить небезопасные ситуации, когда два глобальных объекта взаимно зависят друг от друга). Кроме того, при динамическом связывании модулей может быть неясно, имеют ли разные библиотеки свои собственные экземпляры глобальных переменных или эти глобальные переменные являются общими.

Тестирование и ограничение — исходный код, использующий глобальные переменные, тестировать несколько сложнее, потому что нельзя легко настроить «чистую» среду между запусками. В более общем случае источник, который использует глобальные службы любого рода (например, чтение и запись файлов или баз данных), которые явно не предоставлены этому источнику, трудно тестировать по той же причине. Для взаимодействующих систем возможность тестирования системных инвариантов может потребовать одновременного запуска более одной «копии» системы, что сильно затрудняется любым использованием общих служб, включая глобальную память, которые не предназначены для совместного использования в рамках теста. .

В общем, избегайте глобальных переменных. Если они вам нужны, используйте Q_GLOBAL_STATIC.

Создает глобальный и статический объект типа QGlobalStatic с именем VariableName, который ведет себя как указатель на Type. Объект, созданный Q_GLOBAL_STATIC, инициализирует себя при первом использовании, что означает, что он не увеличит время загрузки приложения или библиотеки. Кроме того, объект инициализируется потокобезопасным способом на всех платформах.

Вы также можете использовать Q_GLOBAL_STATIC_WITH_ARGS. Здесь вы можете найти некоторые встроенные выделения из документации:

Создает глобальный и статический объект типа QGlobalStatic с именем VariableName, инициализированный аргументами Arguments и ведущий себя как указатель на Type. Объект, созданный Q_GLOBAL_STATIC_WITH_ARGS, инициализирует себя при первом использовании, что означает, что он не увеличит время загрузки приложения или библиотеки. Кроме того, объект инициализируется потокобезопасным способом на всех платформах.

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

Порядок инициализации глобальных объектов определяется только внутри единицы трансляции (там это сверху вниз). Нет никакой гарантии между единицами перевода. Типичный обходной путь — обернуть объект в функцию и вернуть ссылку на локальный объект:

ApiManager& apiMng() {
    static ApiManager rc;
    return rc;
}

Локальный объект инициализируется при первом вызове функции (а при использовании C++11 также и потокобезопасным способом). Таким образом, порядок построения объектов с глобальным доступом можно упорядочить удобным способом.

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

Хорошей привычкой в ​​мире C++ было бы избегать глобальных объектов любой ценой - чем более локализован объект, тем он лучше.

Если вам абсолютно необходимо иметь глобальный объект, я думаю, что лучше всего было бы инициализировать объекты в пользовательском порядке в основном - чтобы четко указать порядок инициализации. Тот факт, что вы используете qt, является еще одним аргументом в пользу инициализации в main - вы, вероятно, захотите инициализировать QApplication (который требует argc и argv в качестве входных аргументов) перед любым другим QObject.