C++. Сборник рецептов

Когсуэлл Джефф

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

Пример 2.1. Заголовочный файл

#ifndef MYCLASS_H__ // защита #include, рецепт 2.0

#define MYCLASS_H__

#include <string>

namespace mylib { //

пространства имен, рецепт 2.3

 class AnotherClass; // предварительное объявление класса, рецепт 2.2

 class Logger;

 extern Logger* gpLogger; // объявление внешнего хранилища, рецепт 2.1

 class MyClass {

 public:

std::string getVal const;

// ...

 private:

static int refCount_;

std::string val_;

 };

}

// Встраиваемые определения, рецепт 2.4

inline std::string MyClass::getVal const {

 return(val_);

}

#include "myclass.inl"

} // namespace

#endif // MYCLASS_H__

После написания заголовочного файла также вам будет нужен файл реализации, под которым я понимаю файл .cpp, содержащий не только объявления, но и определения. Файл реализации оказывается менее сложным, чем заголовочный файл, но ради полноты пример 2.2 содержит пример реализации файла, идущего в комплекте с заголовочным файлом из примера 2.1.

Пример 2.2. Файл реализации

#include "myclass.h"

namespace mylib {

 MyClass::refCount_ = 0; // статическое определение, рецепт 8.4

 MyClass::foo { // реализация метода

// ...

 };

}

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

2.1. Обеспечение единственности подключения заголовочного файла

Проблема

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

Решение

В заголовочном файле с помощью

#define

определите макрос и содержимое заголовочного файла подключайте только тогда, когда макрос еще не был определен. Используйте такую комбинацию директив препроцессора

#ifndef

,

#define

и

#endif

,

как я делаю в примере 2.1:

#ifndef MYCLASS_H__ // защита #include

#define MYCLASS_H__

// Здесь поместите все. что требуется...

#endif // MYCLASS_H__

Когда препроцессор сканирует такой заголовочный файл, одной из первых встреченных им вещей будет директива

#ifndef

и следующий за ней символ,

#ifndef

говорит препроцессору перейти на следующую строку только в том случае, если символ

MYCLASS_H__

еще не определен. Если он уже определен, препроцессор должен пропустить код до закрывающей директивы

#endif

. Строка, следующая за

#ifndef

, определяет

MYCLASS_H__

, так что если этот файл при одной и той же компиляции сканируется препроцессором дважды, то второй раз

MYCLASS_H__

будет уже определен. Поместив весь код между

#ifndef

и

#endif

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

Обсуждение

Если вы не используете эту методику, которая называется защитой заголовка, то вы, вероятно, уже видели ошибки компиляции «symbol already defined» (символ уже определен), которые являются следствием отсутствия защитных мер против множественных определений. C++ не позволяет определять один и тот же символ несколько раз, и если вы это сделаете (целенаправленно или случайно), то получите ошибку компилятора. Включение защиты предотвращает такие ошибки, и она стала стандартной методикой.

Определяемый с помощью

#define

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

MYCLASS_H_V301__

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

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

#ifndef MYCLASS_H__

#include "myclass.h"

#endif

Это сокращает процесс включения, поскольку, если макрос

MYCLASS_H__

уже определен, файл

myclass.h

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