Чтение онлайн

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

Рецепт 1.25.

Возможно, что одной из причин популярности C++ является его способность одинаково хорошо подходить для маленьких, средних и больших проектов. Для небольшого прототипа или исследовательского проекта можно написать всего несколько классов, а при росте проекта и увеличении числа сотрудников C++ позволяет масштабировать приложение, разбив его на модули, различающиеся по степени своей независимости. Недостатком здесь является то, что вы должны потратить время на то, чтобы вручную выполнить реорганизацию (добавить пространства имен, реорганизовать физическое расположение заголовочных файлов и т.д.). Обычно это стоит того, так как при этом приложение становится модульным и позволяет отдельным людям сосредоточиться только на их локальной функциональной области.

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

Если вы еще не используете пространства имен, вы, возможно, по крайней мере, слышали о них и уже используете одно из них: пространство имен

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

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

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

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

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

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

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

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

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

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

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

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

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

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