Библиотека программиста

Все, что необходимо начинающему и опытному программисту

23. Делайте заголовочные файлы самодостаточными

Резюме

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

Обсуждение

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

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

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

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

Примеры

Ряд тонких моментов возникает в связи с использованием шаблонов.

Пример 1. Зависимые имена. Шаблоны компилируются в точке, где они определены, с тем исключением, что все зависимые имена или типы не компилируются до точки инстанцирования. Это означает, что template<class T> class Widget с членом std::deque<T> не приведет к ошибке времени компиляции, даже если заголовочный файл <deque> не включен — если при этом не происходит инстанцирование Widget. Поскольку очевидно, что шаблон Widget существует для того, чтобы быть инстанцированным, его заголовочный файл должен содержать строку #include <deque>.

Пример 2. Шаблоны функций-членов и функции-члены шаблонов инстанцируются только при использовании. Предположим, что Widget не имеет члена типа std::deque<T>, но функция-член Widget с именем Transmogrify использует deque. Тогда вызывающая Widget функция может инстанцировать и использовать Widget, даже если заголовочный файл <deque> не включен— до тех пор, пока не используется функция-член Transmogrify. По умолчанию заголовочный файл Widget все же должен включать <deque>, поскольку это необходимо, по крайней мере, для некоторых пользователей Widget. В редких случаях, когда большой заголовочный файл включается только для обеспечения работоспособности нескольких редко используемых функций шаблона, следует подумать о том, чтобы сделать эти функции не членами и вынести их в отдельный заголовочный файл, включающий упомянутый большой файл (см. рекомендацию 44).

24. Используйте только внутреннюю, но не внешнюю защиту директивы #include

Резюме

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

Обсуждение

Каждый заголовочный файл должен использовать внутреннюю защиту директивы #include, чтобы предотвратить переопределения в случае множественного включения данного файла. Например, заголовочный файл foo.h должен иметь такой общий вид:

#ifndef FOO_H_INCLUDED_
#define FOO_H_INCLUDED_
// ... Содержимое файла ...
#endif

Обратите внимание на следующие правила при определении защиты включения.

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

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

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

#ifndef FOO_H_INCLUDED_ // нe рекомендуется
#include "foo.h"
#define FOO_H_INCLUDED_
#endif

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

Исключения

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

Функции и операторы

Если ваша процедура имеет десять параметров — вероятно, вы где-то ошиблись.
— Алан Перлис (Alan Perlis)

Функции, включая перегруженные операторы, представляют собой фундаментальные единицы работы. Как вы увидите позже в разделе "Обработка ошибок и исключения" (в частности, в рекомендации 70), это непосредственно влияет на наши рассуждения о корректности и безопасности кода.

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

В этом разделе наиболее важной нам представляется рекомендация 26 — "Сохраняйте естественную семантику перегруженных операторов".

25. Передача параметров по значению, (интеллектуальному) указателю или ссылке

Резюме

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

Обсуждение

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

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

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

• Всегда описывайте все указатели или ссылки на входные параметры как const.

• Предпочитайте передачу примитивных типов (например, char или float) и объектов-значений с недорогими операциями копирования (например, Point или complex <float>) по значению.

• Входные аргументы прочих пользовательских типов лучше передавать как ссылки на const.

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

Далее приведены рекомендации для выходных параметров (а также параметров для одновременного ввода и вывода информации).

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

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

Не используйте функции с переменным количеством аргументов (см. рекомендацию 98).

26. Сохраняйте естественную семантику перегруженных операторов

Резюме

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

Обсуждение

Хотя все (как мы надеемся) согласны с тем, что не следует реализовывать вычитание как оператор operator+, прочие ситуации не столь очевидны. Например, означает ли оператор operator* вашего класса Tensor скалярное или векторное умножение? Должен ли оператор operator+=(Tensor&t, unsigned u) прибавлять и к каждому из элементов t, или должен изменять размер t? В таких неоднозначных или не поддающихся интуитивному пониманию случаях следует использовать именованные функции, а не прибегать к шифрованию.

Для типов-значений (но не для всех типов; см. рекомендацию 32) следует придерживаться правила: "Если не знаешь, как поступить— поступай так, как int". Подражание поведению операторов встроенных типов и взаимоотношениям между ними гарантирует, что вы никого не приведете в замешательство. Если выбранная вами семантика заставляет кого-то удивленно поднять брови, может быть, перегрузка оператора — не самая лучшая идея?

Программисты ожидают, что операторы идут в связке — если выражение а@b имеет определенный смысл для некоторого определенного вами оператора @ (возможно, после преобразования типов), то задайте сами себе вопрос: можно ли написать b@a без неприятных последствий? Можно ли написать a@=b? (См. рекомендацию 27.) Если оператор имеет обратный оператор (например, + и -, * и /), то поддерживаются ли они оба?

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

Исключения

Имеются высокоспециализированные библиотеки (например, генераторы синтаксических анализаторов), в предметной области которых соглашения о семантике операторов существенно отличаются от их значений в C++ (например, при работе с регулярными выражениями оператор operator* может использоваться для выражения "ноль или большее количество"). Предпочтительно найти альтернативу необычной перегрузке оператора (например, в регулярных выражениях используются строки, так что * может использоваться естественным образом, без перегрузки операторов). Если все же после тщательных размышлений вы решили использовать операторы, убедитесь, что вы четко определили единую схему для всех ваших соглашений, и при этом не затеяли опасные игры со встроенными операторами.

<< Назад         В начало         Далее >>

Библиотека программиста. 2009.
Администратор: admin@programmer-lib.ru