Всегда будут вещи, которые мы будем хотеть сказать в наших программах и которые трудно сформулировать на любом языке программирования.
(— Алан Перлис (Alan Perlis))
Последней (не по важности) темой книги является корректность типов — очень важное свойство программ, которое вы должны изо всех сил стараться поддерживать. Теоретически корректная с точки зрения типов функция не может обратиться к нетипизированной памяти или вернуть неверные значения. На практике, если ваш код поддерживает корректность типов, он тем самым избегает большого количества неприятных ошибок, от непереносимости программ до порчи содержимого памяти и неопределенного поведения программ.
Основная идея поддержки корректности типов — всегда считывать информацию в том формате, в котором она была записана. Иногда С++ позволяет легко нарушить это правило; приведенные в этом разделе рекомендации помогут вам избежать подобных ошибок.
В этом разделе мы считаем наиболее значимой рекомендацию 91 — "Работайте с типами, а не с представлениями". Система типов — ваш друг и верный союзник. Воспользуйтесь ее помощью и попытайтесь не злоупотреблять ее доверием.
Избегайте явного выбора типа объекта для настройки поведения. Используйте шаблоны и виртуальные функции для того, чтобы поведение объекта определялось его типом, а не вызывающим кодом.
Обсуждение
Настройка поведения в зависимости от типа объекта с использованием инструкции выбора
switch
— это ненадежный, чреватый ошибками, небезопасный метод, представляющий собой перенос методов С или Fortran в С++. Это жесткая технология, заставляющая вас всякий раз при добавлении новых возможностей переписывать уже готовый и отлаженный код. Этот метод небезопасен еще и потому, что компилятор не может подсказать вам, что вы забыли внести дополнения в какую-то из инструкций
switch
при добавлении нового типа.
В идеале добавление новых возможностей в программу должно осуществляться добавлением нового кода, а не изменением старого (см. рекомендацию 37). В реальной жизни это не всегда так — зачастую в дополнение к написанию нового кода мы вынуждены вносить изменения в уже имеющийся код. Такие изменения, однако, крайне нежелательны и должны быть минимизированы по двум причинам. Во-первых, изменения могут нарушить имеющуюся функциональность. Во-вторых, они препятствуют масштабируемости при росте системы и добавлении новых возможностей, поскольку количество "узлов поддержки", к которым надо возвращаться и вносить изменения, все время возрастает. Это наблюдение приводит к принципу Открытости-Закрытости, который гласит: любая сущность (например, класс или модуль) должна быть открыта для расширений, но закрыта для изменений (см. [Martin96c] и [Meyer00]).
Каким же образом мы можем написать код, который будет легко расширяем без внесения изменений? Используйте полиморфизм для написания кода в терминах абстракций (см. также рекомендацию 36), после чего при необходимости добавления функциональности это можно будет сделать путем разработки и добавления различных реализаций упомянутых абстракций. Шаблоны и виртуальные функции образуют барьер для зависимостей между кодом, использующим абстракции, и кодом, их реализующим (см. рекомендацию 64).
Конечно, управление зависимостями обусловлено выбором верных абстракций. Если абстракции несовершенны, добавление новой функциональности потребует изменений интерфейса (а не просто добавления новых реализаций интерфейса), которые обычно влекут за собой значительные изменения существующего кода. Но абстракции потому и называются "абстракциями", что предполагается их большая стабильность по сравнению с "деталями", т.е. возможными реализациями абстракций.
Совсем иначе обстоит дело с предельно детализированным кодом, который использует мало абстракций или вовсе обходится без них, работая исключительно с конкретными типами и их отдельными операциями. Добавление новой функциональности в такой код — сущее мучение.
Примеры
Пример. Рисование фигур. Классический пример — рисование различных объектов. Типичный подход в стиле С использует выбор типа. Для этого определяется член-перечисление
id_
, который хранит тип каждой фигуры — прямоугольник, окружность и т.д. Рисующий код выполняет необходимые действия в зависимости от выбранного типа:
class Shape { // ...
enum { RECTANGLE, TRIANGLE, CIRCLE } id_;
void Draw() const {
switch (id_) { // плохой метод
case RECTANGLE:
// ... Код для прямоугольника …
break;
case TRIANGLE:
// ... Код для треугольника …
break;
case CIRCLE:
// ... Код для окружности …
break;
default: // Плохое решение
assert(!"при добавлении нового типа надо "
"обновить эту конструкцию" );
break;
}
}
};
Такой код сгибается под собственным весом, он хрупок, ненадежен и сложен. В частности, он страдает транзитивной циклической зависимостью, о которой говорилось в рекомендации 22. Ветвь по умолчанию конструкции
switch
— четкий симптом синдрома "не знаю, что мне делать с этим типом". И все эти болезненные неприятности полностью исчезают, стоит только вспомнить, что С++ — объектно-ориентированный язык программирования:
class Shape { // ...
virtual void Draw() const = 0; // Каждый производный
// класс реализует свою функцию
};
В качестве альтернативы (или в качестве дополнения) рассмотрим реализацию, которая следует совету по возможности принимать решения во время компиляции (см. рекомендацию 64):
template<class S>
void Draw(const S& shape) {
shape.Draw(); // может быть виртуальной, а может и не быть
}; // См. рекомендацию 64
Теперь ответственность за рисование каждой геометрической фигуры переходит к реализации самой фигуры, и синдром "не знаю, что делать с этим типом" просто невозможен.
Не пытайтесь делать какие-то предположения о том, как именно объекты представлены в памяти. Как именно следует записывать и считывать объекты из памяти — пусть решают типы объектов.
Обсуждение
Стандарт С++ дает очень мало гарантий по поводу представления типов в памяти.
• Целые числа используют двоичное представление.
• Для отрицательных чисел используется дополнительный код числа в двоичной системе.
• Обычные старые типы (Plain Old Data, POD[5]) имеют совместимое с С размещение в памяти: переменные-члены хранятся в порядке их объявления.
• Тип
int
занимает как минимум 16 битов.
В частности, достаточно распространенные соглашения не гарантированы ни для всех имеющихся архитектур, ни тем более для архитектур, которые могут появиться в будущем. Так что не забывайте о следующем.
• Размер
int
не равен ни 32 битам, ни какому-либо иному фиксированному размеру.
• Указатели и целые числа не всегда имеют один и тот же размер и не могут свободно преобразовываться друг в друга.
• Размещение класса в памяти не всегда приводит к размещению базового класса и членов в указанном порядке.
• Между членами класса (даже если они являются POD) могут быть промежутки в целях выравнивания.
•
offsetof
работает только для POD, но не для всех классов (хотя компилятор может и не сообщать об ошибках).
• Класс может иметь скрытые поля.
• Указатели могут быть совсем не похожи на целые числа. Если два указателя упорядочены и вы можете преобразовать их в целые числа, то получающиеся значения могут быть упорядочены иначе.
• Нельзя переносимо полагаться на конкретное размещение автоматических переменных в памяти или на направление роста стека.
• Указатели на функции могут иметь размер, отличный от размера указателя
void*
, несмотря на то, что некоторые API заставляют вас предположить, что их размеры одинаковы.
• Из-за вопросов выравнивания вы не можете записывать ни один объект по произвольному адресу в памяти.
Просто корректно определите типы, а затем читайте и записывайте данные с использованием указанных типов вместо работы с отдельными битами, словами и адресами. Модель памяти С++ гарантирует эффективную работу, не заставляя вас при этом работать с представлениями данных в памяти. Так и не делайте этого.
Как гласит римская пословица, у лжи короткие ноги. Не пытайтесь использовать
reinterpret_cast
, чтобы заставить компилятор рассматривать биты объекта одного типа как биты объекта другого типа. Такое действие противоречит безопасности типов. Обсуждение
Вспомните: Если вы лжете компилятору, он будет мстить (Генри Спенсер).
Преобразование
reinterpret_cast
отражает представления программиста о представлении объектов в памяти, т.е. программист берет на себя ответственность за то, что он лучше компилятора знает, что можно и что нельзя. Компилятор молча сделает то, что вы ему скажете, но применять такую грубую силу в отношениях с компилятором — последнее дело. Избегайте каких-либо предположений о представлении данных, поскольку такие предположения очень сильно влияют на безопасность и надежность вашего кода.
Кроме того, реальность такова, что результат применения
reinterpret_cast
еще хуже, чем просто насильственная интерпретация битов объекта (что само по себе достаточно нехорошо). За исключением некоторых гарантированно обратимых преобразований результат работы
reinterpret_cast
зависит от реализации, так что вы даже не знаете точно, как именно он будет работать. Это очень ненадежное и непереносимое преобразование. Исключения
Некоторые низкоуровневые специфичные для данной системы программы могут заставить вас применить
reinterpret_cast
к потоку битов, проходящих через некоторый порт, или для преобразования целых чисел в адреса. Используйте такое небезопасное преобразование как можно реже и только в тщательно скрытых за абстракциями функциях, чтобы ваш код можно было переносить с минимальными изменениями. Если вам требуется преобразование между указателями несвязанных типов, лучше выполнять его через приведение к
К указателям на динамические объекты не следует применять преобразование
static_cast
. Используйте безопасные альтернативы — от
dynamic_cast
до перепроектирования. Обсуждение
Подумайте о замене
static_cast
более мощным оператором
dynamic_cast
, и вам не придется запоминать, в каких случаях применение
static_cast
безопасно, а в каких — чревато неприятностями. Хотя dynamic_cast может оказаться немного менее эффективным преобразованием, его применение позволяет обнаружить неверные преобразования типов (но не забывайте о рекомендации 8). Использование
static_cast
вместо
dynamic_cast
напоминает экономию на ночном освещении, когда выигрыш доллара в год оборачивается переломанными ногами.
При проектировании постарайтесь избегать понижающего приведения. Перепроектируйте ваш код таким образом, чтобы такое приведение стало излишним. Если вы видите, что передаете в функцию базовый класс там, где в действительности потребуется производный класс, проследите всю цепочку вызовов, чтобы понять, где же оказалась потерянной информация о типе; зачастую изменение пары прототипов оказывается замечательным решением, которое к тому же делает код более простым и понятным.
Чрезмерное применение понижающего приведения может служить признаком слишком бедного интерфейса базового класса. Такой интерфейс может привести к тому, что большая функциональность определяется в производных классах, и всякий раз при необходимости расширения интерфейса приходится использовать понижающее приведение. Одно из решений данной проблемы — перепроектирование базового интерфейса в целях повышения функциональности.
Тогда и только тогда, когда становятся существенны накладные расходы, вызванные применением
dynamic_cast
(см. рекомендацию 8), следует подумать о разработке собственного преобразования типов, который использует
dynamic_cast
при отладке и
static_cast
в окончательной версии (см. [Stroustrup00]):
template<class To, class From> To checked_cast(From* from) {
assert(dynamic_cast<To>(from) ==
static_cast<To>(from) && "checked_cast failed" );
return static_cast<To>(from);
}
template<class To, class From> To checked_cast(From& from) {
Эта пара функций (по одной для указателей и ссылок) просто проверяет согласованность двух вариантов преобразования. Вы можете либо самостоятельно приспособить
checked_cast
для своих нужд, либо использовать имеющийся в библиотеке. Ссылки
, может привести к неопределенному поведению, а кроме того, это свидетельство плохого стиля программирования даже в том случае, когда применение такого преобразования вполне законно. Обсуждение
Применение
const
— это дорога с односторонним движением, и, воспользовавшись этим спецификатором, вы не должны давать задний ход. Если вы отменяете
const
для объекта, который изначально был объявлен как константный, задний ход приводит вас на территорию неопределенного поведения. Например, компилятор может (и, бывает, так и поступает) поместить константные данные в память только для чтения (ROM) или в страницы памяти, защищенные от записи. Отказ от
const
у такого истинно константного объекта — преступный обман, зачастую караемый аварийным завершением программы из-за нарушения защиты памяти.
Даже если ваша программа не потерпит крах, отмена
const
представляет собой отмену обещанного и не делает того, чего от нее зачастую ожидают. Например, в приведенном фрагменте не происходит выделения массива переменной длины:
void Foolish(unsigned int n) {
const unsigned int size = 1;
const_cast<unsigned int&>(size) = n; // Не делайте так!
char buffer[size]; // Размер массива
// ... // все равно равен 1
}
В С++ имеется одно неявное преобразование
const_cast
из строкового литерала в
char*
:
char* weird = "Trick or treat?";
Компилятор молча выполняет преобразование
const_cast
из
const char[16]
в
char*
. Это преобразование позволено для совместимости с API в стиле С, хотя и представляет собой дыру в системе типов С++. Строковые литералы могут размещаться в памяти только для чтения, и попытка изменения такой строки может вызвать нарушение защиты памяти. Исключения
Преобразование, отменяющее
const
, может оказаться необходимым для вызова функции API, некорректно указывающей константность (см. рекомендацию 15). Оно также полезно, когда функция, которая должна получать и возвращать ссылку одного и того же типа, имеет как константную, так и неконстантную перегрузки, причем одна из них вызывает другую:
Возраст не всегда означает мудрость. Старое преобразование типов в стиле С имеет различную (и часто опасную) семантику в зависимости от контекста, спрятанную за единым синтаксисом. Замена преобразования типов в стиле С преобразованиями С++ поможет защититься от неожиданных ошибок.
Обсуждение
Одна из проблем, связанных с преобразованием типов в стиле С, заключается в том, что оно использует один и тот же синтаксис для выполнения несколько разных вещей, в зависимости от таких мелочей, как, например, какие именно заголовочные файлы включены при помощи директивы
#include
. Преобразования типов в стиле С++, сохраняя определенную опасность, присущую преобразованиям вообще, имеют четко документированное предназначение, их легко найти, дольше писать (что дает время дважды подумать при их использовании), и не позволяют незаметно выполнить опасное преобразование
reinterpret_cast
(см. рекомендацию 92).
Рассмотрим следующий код, в котором
Derived
— производный от базового класса
Base
:
extern void Fun(Derived*);
void Gun(Base* pb) {
// Будем считать, что функция Gun знает, что pb в
// действительности указывает на объект типа Derived и
), то компилятор имеет всю необходимую информацию о размещении объекта, чтобы выполнить все необходимые действия по корректировке указателя при преобразовании от
Base
к
Derived
. Но если автор
Gun
забыл включить соответствующий файл определения, и функции
Gun
видно только предварительное объявление класса
Derived
, то компилятор будет полагать, что
Base
и
Derived
— несвязанные типы, и интерпретирует биты указателя
Base*
как биты указателя
Derived*
, не делая никаких коррекций, которые могут диктоваться размещением объекта в памяти!
Коротко говоря, если вы забудете включить определение класса, то ваш код может аварийно завершиться без видимых причин, при том что компилятор не сообщил ни об одной ошибке. Избавимся от проблемы следующим способом:
extern void Fun(Derived*);
void Gun(Base* pb) {
// Если мы гарантированно знаем, что pb на самом деле
// указывает на объект типа Derived:
// Преобразование в стиле С++
Derived* pd = static_cast<Derived*>(pb);
// В противном случае следует использовать
// = dynamic_cast<Derived*>(pb);
Fun(pd);
}
Теперь, если у компилятора недостаточно статической информации об отношениях между
Base
и
Derived
, он выведет сообщение об ошибке, вместо того чтобы автоматически применить побитовое (и потенциально опасное) преобразование
reinterpret_cas
t (см. рекомендацию 92).
Преобразования в стиле С++ могут защитить корректность вашего кода в процессе эволюции системы. Пусть, например, у вас есть иерархия с корнем в
Employee
, и вам надо определить уникальный идентификатор
ID
для каждого объекта
Employee
. Вы можете определить ID как указатель на сам объект
Employee
. Указатели однозначно идентифицируют объекты, на которые указывают, и могут сравниваться на равенство друг другу — что в точности то, что нам и надо. Итак, запишем:
typedef Employee* EmployeeID;
Employee& Fetch(EmployeeID id) {
return *id;
}
Пусть вы кодируете часть системы с данным дизайном. Пусть позже вам требуется сохранять ваши записи в реляционной базе данных. Понятно, что сохранение указателей — не то, что вам требуется. В результате вы изменяете дизайн так, чтобы каждый объект имел уникальный целочисленный идентификатор. Тогда целочисленный идентификатор может храниться в базе данных, а хэш-таблица отображает идентификаторы на объекты
Employee
. Теперь
typedef
выглядит следующим образом:
typedef int EmployeeID;
Employee& Fetch( EmployeeID id ) {
return employeeTable_.lookup(id);
}
Это корректный дизайн, и вы ожидаете, что любое неверное употребление
EmployeeID
должно привести к ошибке времени компиляции. Так и получается, за исключением следующего небольшого фрагмента:
void TooCoolToUseNewCasts(EmployeeID id) {
Secretary* pSecretary = (Secretary*)id; // Плохо:
// ... // преобразование в стиле С
}
При использовании старой инструкции
typedef
преобразование в стиле С выполняет
static_cast
, при новой будет выполнено
reinterpret_cast
с некоторым целым числом, что даст нам неопределенное поведение программы (см. рекомендацию 92).
Преобразования в стиле С++ проще искать в исходных текстах при помощи автоматического инструментария наподобие
grep
(но никакое регулярное выражение
grep
не позволит выловить синтаксис преобразования типов в стиле С). Поскольку преобразования очень опасны (в особенности
static_cast
для указателей и
reinterpret_cast
; см. рекомендацию 92), использование автоматизированного инструментария для их отслеживания — неплохая идея. Ссылки
Не работайте рентгеновским аппаратом (см. рекомендацию 91). Не используйте
memcpy
и
memcmp
для копирования или сравнения чего-либо структурированного более, чем обычная память. Обсуждение
Функции
memcpy
и
memcmp
нарушают систему типов. Использовать
memcpy
для копирования объектов — это то же, что использовать ксерокс для копирования денег, а сравнивать объекты при помощи
memcmp
— то же, что сравнивать двух леопардов по количеству пятен. Инструменты и методы могут казаться подходящими для выполнения работы, но они слишком грубы для того, чтобы сделать ее правильно.
Объекты С++ предназначены для сокрытия данных (возможно, наиболее важный принцип в разработке программного обеспечения; см. рекомендацию 11). Объекты скрывают данные (см. рекомендацию 41) и предоставляют точные абстракции для копирования этих данных посредством конструкторов и операторов присваивания (см. рекомендации с 52 по 55). Пройтись по ним грубым инструментом типа
memcpy
— серьезное нарушение принципа сокрытия информации, которое зачастую приводит к утечкам памяти и ресурсов (в лучшем случае), аварийному завершению программы (в случае похуже) или неопределенному поведению (в самом худшем случае). Например:
{
// Создаем два int в памяти
shared_ptr<int> p1(new int), p2(new int);
memcpy(&p1, &p2, sizeof(p1)); // Так делать нельзя!!!
} // Утечка памяти: p2 никогда не удаляется
// повреждение памяти: p1 удаляется дважды
Неверное применение
memcpy
может влиять на такие фундаментальные свойства, как тип и сущность объекта. Компиляторы часто добавляют к полиморфным объектам скрытые данные (так называемый указатель на виртуальную таблицу), которые определяют сущность объекта во время выполнения программы. В случае множественного наследования в объекте содержится несколько таких таблиц, с различными смещениями внутри объекта, и большинство реализаций добавляют дополнительные внутренние указатели при виртуальном наследовании. При обычном использовании компилятор принимает меры для корректного управления всеми скрытыми полями; применение
memcpy
способно внести в этот механизм только хаос.
Аналогично, функция
memcmp
— неподходящий инструмент для сравнения чего-то более сложного, чем просто наборы битов. Иногда эта функция делает слишком мало (например, сравнение строк в стиле С — не то же, что и сравнение указателей, при помощи которых эти строки реализованы). А иногда, как это ни парадоксально,
memcmp
делает слишком много (например,
memcmp
может совершенно напрасно сравнивать байты, которые не являются частью состояния объекта, такие как заполнители, вставленные компилятором для выравнивания). В обоих случаях результат сравнения оказывается неверным. Ссылки
Хитрость все равно остается ложью: объединения можно использовать для получения "преобразования типа без преобразования", записывая информацию в один член и считывая из другого. Однако это еще более опасно и менее предсказуемо, чем применение
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-структуры являются членами объединения и начинаются с полей одних и тех же типов, можно записывать одно из таких полей, а затем считывать данные из другого.
Наличие троеточий в С++ — опасное наследие С. Избегайте их в своих программах; используйте вместо этого высокоуровневые конструкции и библиотеки С++.
Обсуждение
Функции с переменным количеством аргументов достаточно удобны, однако использование неизвестных аргументов в стиле C — не лучший способ получения таких функций. Эти аргументы имеют много серьезных недостатков.
• Недостаточная безопасность типов. По сути, троеточие говорит компилятору: "Выключи все проверки. С этого момента я все беру на себя, и теперь начинает работать
reinterpret_cast
". (См. рекомендацию 92).
• Сильное связывание и необходимость согласования вызываемого и вызывающего кода вручную. Проверка типов языком оказывается отключена, так что вызывающий код должен использовать иные способы для сообщения о типах передаваемых аргументов. Такие протоколы (например, форматная строка
printf
) подвержены ошибкам и небезопасны, поскольку не могут быть полностью проверены ни вызывающим, ни вызываемым кодом. (См. рекомендацию 99.)
• Неопределенное поведение для объектов типов, являющихся классами. Передача чего бы то ни было кроме POD и примитивных типов вместо троеточий приводит к неопределенному поведению в С++. К сожалению, большинство компиляторов даже не предупреждает об этом.
• Неизвестное количество аргументов. Даже в случае простейших функций с переменным количеством аргументов (например, min) вам все равно требуется протокол, позволяющий указать количество передаваемых аргументов. (Как ни смешно, но это, пожалуй, хорошее свойство, поскольку является еще одним препятствием широкому распространению функций с переменным числом аргументов.)
Избегайте троеточий в сигнатурах ваших функций. Избегайте вызова функций с переменным количеством аргументов со своими собственными сигнатурами, даже если это вполне корректные функции из стандартной библиотеки С, такие как
sprintf
. Вызовы
sprintf
часто выглядят более компактными и простыми для понимания, чем эквивалентные вызовы с использованием форматирования
stringstream
и операторов
operator<<
— так же, как легче сесть в машину, не оборудованную ремнями и подушкой безопасности, да еще и без дверец. Удобства при использовании таких функций не стоят возникающего при этом риска. Функции в стиле
printf
представляют собой серьезную проблему безопасности (см. [Cowan01]), так что имеется целая отрасль разработки инструментария для поиска ошибок такого рода (см. [Tsai01]).
Лучше использовать безопасные в смысле типов библиотеки, которые поддерживают переменное количество аргументов иными средствами. Например, библиотека форматирования [Boost] использует новейшие средства С++ для совмещения безопасности со скоростью и удобством.
Вы же не используете просроченные лекарства? И недействительные объекты, и "антикварные", но небезопасные функции способны навредить здоровью ваших программ.
Обсуждение
Имеется три основные категории недействительных объектов.
• Уничтоженные объекты. Типичными примерами таких объектов являются автоматические объекты, вышедшие из области видимости, и удаленные динамические объекты. После того как вы вызвали деструктор объекта, его время жизни истекло, и любые действия с ним небезопасны и приводят к непредсказуемым последствиям.
• Семантически недействительные объекты. Типичные примеры включают "висячие" указатели на удаленные объекты (например, указатель
p
после выполнения
delete p;
) и недействительные итераторы (например,
vector<T>::iterator i
после вставки в начало контейнера, к которому обращается итератор). Заметим, что висячие указатели и недействительные итераторы концептуально идентичны, и последние часто непосредственно содержат первые. Обычно небезопасно и непредсказуемо делать что-либо с такими указателями и итераторами, за исключением присваивания другого корректного значения недействительному объекту (например,
p = new Object;
или
i = v.begin();
).
• Объекты, которые никогда не были действительными. Примеры включают объекты, "полученные" путем преобразования указателя с использованием
reinterpret_cast
(см. рекомендацию 92) или при обращении за пределы границ массива.
Никогда не забывайте о времени жизни объекта и его корректности. Не разыменовывайте недействительные итераторы и указатели. Не делайте никаких предположений о том, что делает и чего не делает оператор
delete
; освобожденная память — это освобожденная память, и обращений к ней не должно быть ни при каких условиях. Не пытайтесь играться со временем жизни объекта путем вызова деструктора вручную (например,
obj.~T()
) с последующим вызовом размещающего
new
(см. рекомендацию 55).
Не используйте небезопасное наследство С:
strcpy
,
strncpy
,
sprintf
или прочие функции, которые выполняют запись в буфер без проверки выхода за его пределы. Функция
strcpy
не выполняет проверки границ буфера, а функция [C99]
strncpy
выполняет проверку, но не добавляет нулевой символ при выходе на границу. Обе эти функции — потенциальный источник неприятностей. Используйте современные, более безопасные и гибкие структуры и функции, такие, которые имеются в стандартной библиотеке С++ (см. рекомендацию 77). Они не всегда совершенно безопасны (в основном это связано с вопросами эффективности), но существенно меньше подвержены ошибкам и позволяют создавать гораздо более безопасный код. Ссылки
Полиморфная работа с массивами — большая ошибка. К сожалению, обычно компилятор никак на нее не реагирует. Не попадайтесь в эту ловушку!
Обсуждение
Указатели служат одновременно для двух целей: в качестве малого размера идентификаторов объектов и в качестве итераторов для массивов (они могут обходить массивы объектов с использованием арифметики указателей). В качестве идентификаторов имеет смысл рассматривать указатель на
Derived
как указатель на
Base
. Однако как только мы переходим ко второй цели, такая замена не работает, поскольку массив объектов
Derived
— совсем не то же, что и массив объектов
Base
. Чтобы проиллюстрировать сказанное, заметим, что и мышь, и слон — оба млекопитающие, но это не значит, что колонна из ста слонов будет по длине такой же, что и колонна из ста мышей.
Размер имеет значение. При замене указателя на
Derived
указателем на
Base
компилятор точно знает, как следует подкорректировать (при необходимости) указатель, поскольку у него есть достаточное количество информации об обоих классах. Однако при выполнении арифметических операций над указателем
p
на
Base
компилятор вычисляет
p[n]
как
*(p+n*sizeof(Base)
), таким образом полагаясь на то, что объекты, находящиеся в памяти, — это объекты типа
Base
, а не некоторого производного типа, который может иметь другой размер. Представляете, какая ерунда может получиться при работе с массивом объектов
Derived
, если вы преобразуете указатель на начало этого массива в указатель типа
Base*
(что компилятор вполне допускает), а затем примените арифметические операции к этому указателю (что компилятор также пропустит, не моргнув глазом)!
Такие неприятности представляют собой результат взаимодействия двух концепций — заменимости указателей на производный класс указателями на базовый класс, и унаследованной от С арифметикой указателей, которая считает указатели мономорфными и использует при вычислениях только статическую информацию.
Для хранения массива полиморфных объектов вам нужен массив (а еще лучше — контейнер; см. рекомендацию 77) указателей на базовый класс (например, обычных указателей или, что еще лучше, интеллектуальных указателей
shared_ptr
; см. рекомендацию 79). Тогда каждый указатель массива указывает на полиморфный объект, скорее всего, объект в динамически выделенной памяти. (Если вы хотите обеспечить интерфейс контейнера полиморфных объектов, вам надо инкапсулировать весь массив и предоставить соответствующий полиморфный интерфейс для выполнения итераций.)
Кстати, одна из причин, по которой в интерфейсах следует предпочитать ссылки указателям, заключается в том, чтобы было совершенно очевидно, что речь идет только об одном объекте, а не о массиве объектов.
Неформально POD означает любой тип, представляющий собой набор простых данных, возможно, с пользовательскими функциями-членами для удобства. Говоря более строго, POD представляет собой класс или объединение, у которого нет пользовательского конструктора, копирующего присваивания, и деструктора, а также нет (нестатических) членов-данных, являющихся ссылками, указателями на члены или не являющихся POD. — Прим. ред.
