• Семантически недействительные объекты. Типичные примеры включают "висячие" указатели на удаленные объекты (например, указатель

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

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

(см. рекомендацию 92) или при обращении за пределы границ массива.

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

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

Не используйте небезопасное наследство С:

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

[C99] • [Sutter00] §1 • [Sutter04] §2-3

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

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

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

Размер имеет значение. При замене указателя на

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

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

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

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

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

[C++TR104] • [Dewhurst03] §33, §89 • [Sutter00] §36 • [Meyers96] §3

Примечание: для удобства читателей весь список литературы доступен по адресу http://www.gotw.ca/publications/c++cs/bibliography.htm

Ссылки, выделенные полужирным шрифтом (например, [Abrahams96]), представляют собой гиперссылки в приведенной выше странице.

[Abelson96] Abelson H. and Sussman G. J. Structure and Interpretation of Computer Programs (2nd Edition) (MIT Press, 1996).

[Abrahams96] Abrahams D. Exception Safety in STLport. STLport website, 1996.

[Abrahams01a] Abrahams D. Exception Safety in Generic Components, in Jazayeri M., Loos R., Musser D. (eds.), Generic Programming: International Seminar on Generic Programming, Dagstuhl Castle, Germany, April/May 1998, Selected Papers. Lecture Notes in Computer Science 1766 (Springer, 2001).