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

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

97. Не используйте объединения для преобразований

Резюме

Хитрость все равно остается ложью: объединения можно использовать для получения "преобразования типа без преобразования", записывая информацию в один член и считывая из другого. Однако это еще более опасно и менее предсказуемо, чем применение reinterpret_cast (см. рекомендацию 92).

Обсуждение

Не считывайте данные из поля объединения, если последняя запись была не в это же поле. Чтение из поля, отличного от поля, в которое производилась запись, имеет неопределенное поведение, и использование этого метода еще хуже, чем применение reinterpret_cast (см. рекомендацию 92); в последнем случае компилятор, как минимум, может предупредить программиста и не допустить "невозможной интерпретации" наподобие указателя в char. При использовании для этой цели объединения никакая интерпретация не приведет к ошибке времени компиляции (как и к надежному результату).

Рассмотрим фрагмент кода, предназначенного для сохранения значения одного типа (char*) и выборки битов этого значения в виде величины иного типа (long):

union {
    long intValue_;
    char* pointerValue_;
};

pointerValue_ = somePointer;
long int gotcha = intValue_;

Здесь есть две проблемы.

• Данный код требует слишком многого. Он полагается на то, что sizeof(long) и sizeof(char*) равны и что их битовые представления идентичны. Эти утверждения справедливы не для всех возможных реализаций (см. рекомендацию 91).

• Он скрывает свое предназначение как от человека, так и от компилятора. Игры с объединениями затрудняют для компилятора поиск ошибок, связанных с типами, а для человека — выявление логических ошибок.

Исключения

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

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

Резюме

Наличие троеточий в C++ — опасное наследие С. Избегайте их в своих программах; используйте вместо этого высокоуровневые конструкции и библиотеки C++.

Обсуждение

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

• Недостаточная безопасность типов. По сути, троеточие говорит компилятору: "Выключи все проверки. С этого момента я все беру на себя, и теперь начинает работать reinterpret_cast". (См. рекомендацию 92).

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

• Неопределенное поведение для объектов типов, являющихся классами. Передача чего бы то ни было кроме POD и примитивных типов вместо троеточий приводит к неопределенному поведению в C++. К сожалению, большинство компиляторов даже не предупреждает об этом.

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

Избегайте троеточий в сигнатурах ваших функций. Избегайте вызова функций с переменным количеством аргументов со своими собственными сигнатурами, даже если это вполне корректные функции из стандартной библиотеки С, такие как sprintf. Вызовы sprintf часто выглядят более компактными и простыми для понимания, чем эквивалентные вызовы с использованием форматирования stringstream и операторов operator<< — так же, как легче сесть в машину, не оборудованную ремнями и подушкой безопасности, да еще и без дверец. Удобства при использовании таких функций не стоят возникающего при этом риска. Функции в стиле printf представляют собой серьезную проблему безопасности, так что имеется целая отрасль разработки инструментария для поиска ошибок такого рода.

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

99. Не используйте недействительные объекты и небезопасные функции

Резюме

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

Обсуждение

Имеется три основные категории недействительных объектов.

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

• Семантически недействительные объекты. Типичные примеры включают "висячие" указатели на удаленные объекты (например, указатель р после выполнения del ete p;) и недействительные итераторы (например, vector<T>:."iterator i после вставки в начало контейнера, к которому обращается итератор). Заметим, что висячие указатели и недействительные итераторы концептуально идентичны, и последние часто непосредственно содержат первые. Обычно небезопасно и непредсказуемо делать что-либо с такими указателями и итераторами, за исключением присваивания другого корректного значения недействительному объекту (например, р = new Object; или i = v.begin();).

• Объекты, которые никогда не были действительными. Примеры включают объекты, "полученные" путем преобразования указателя с использованием reinterpret_cast (см. рекомендацию 92) или при обращении за пределы границ массива.

Никогда не забывайте о времени жизни объекта и его корректности. Не разыменовывайте недействительные итераторы и указатели. Не делайте никаких предположений о том, что делает и чего не делает оператор delete; освобожденная память — это освобожденная память, и обращений к ней не должно быть ни при каких условиях. Не пытайтесь играться со временем жизни объекта путем вызова деструктора вручную (например, obj.~Т()) с последующим вызовом размещающего new (см. рекомендацию 55).

Не используйте небезопасное наследство С: strcpy, strncpy, sprintf или прочие функции, которые выполняют запись в буфер без проверки выхода за его пределы. Функция strcpy не выполняет проверки границ буфера, а функция strncpy выполняет проверку, но не добавляет нулевой символ при выходе на границу. Обе эти функции — потенциальный источник неприятностей. Используйте современные, более безопасные и гибкие структуры и функции, такие, которые имеются в стандартной библиотеке C++ (см. рекомендацию 77). Они не всегда совершенно безопасны (в основном это связано с вопросами эффективности), но существенно меньше подвержены ошибкам и позволяют создавать гораздо более безопасный код.

100. Не рассматривайте массивы полиморфно

Резюме

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

Обсуждение

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

Размер имеет значение. При замене указателя на Derived указателем на Base компилятор точно знает, как следует подкорректировать (при необходимости) указатель, поскольку у него есть достаточное количество информации об обоих классах. Однако при выполнении арифметических операций над указателем p на Base компилятор вычисляет p[n] как *(p+n*sizeof(Base)), таким образом полагаясь на то, что объекты, находящиеся в памяти, — это объекты типа Base, а не некоторого производного типа, который может иметь другой размер. Представляете, какая ерунда может получиться при работе с массивом объектов Derived, если вы преобразуете указатель на начало этого массива в указатель типа Base* (что компилятор вполне допускает), а затем примените арифметические операции к этому указателю (что компилятор также пропустит, не моргнув глазом)!

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

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

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

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

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