Стандарты программирования на С++

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

Таким образом, в коде инициализации любого объекта уровня пространства имен вы не можете полагаться на то, что уже инициализирован некоторый объект, определенный в другой единице компиляции. Это же касается и динамически инициализируемых переменных примитивных типов (пример такого кода на уровне пространства имен: bool reg_success = LibRegister("mylib");).

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

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

Ссылки

[Dewhurst03] §55 • [Gamma95] • [McConnell93] §5.1-4 • [Stroustrup00] §9.4.1, §10.4.9

22. Минимизируйте зависимости определений и избегайте циклических зависимостей

Резюме

Избегайте излишних зависимостей. Не включайте при помощи директивы #include определения там, где достаточно предварительного объявления.

Избегайте взаимозависимостей. Циклические зависимости возникают, когда два модуля непосредственно или опосредованно зависят друг от друга. Модуль представляет собой обособленную единицу; взаимозависимые модули не являются полностью отдельными модулями, будучи по сути частями одного большего модуля. Таким образом, циклические зависимости являются противниками модульности и представляют угрозу большим проектам. Избегайте их.

Обсуждение

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

• Когда вам необходимо знать размер объекта С. Например, при создании объекта С в стеке или при использовании его в качестве непосредственно хранимого (не через указатель) члена другого класса.

• Когда вам требуется имя или вызов члена С. Например, когда вы вызываете функцию-член этого класса.

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

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

class Child; // Устранение циклической зависимости

class Parent { // ...

 Child* myChild_;

};

// возможно, в другом заголовочном файле

class Child { // ...

 Parent* myParent_;

};