Стандарты программирования на С++. 101 правило и рекомендация

Александреску Андрей

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

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

Ссылки

[Dewhurst03] §69, §96 • [Martin96c] • [Meyer00] • [Stroustrup00] §12.2.5 • [Sutter04] §36

91. Работайте с типами, а не с представлениями

Резюме

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

Обсуждение

Стандарт С++ дает очень мало гарантий по поводу представления типов в памяти.

• Целые числа используют двоичное представление.

• Для отрицательных чисел используется дополнительный код числа в двоичной системе.

• Обычные старые типы (Plain Old Data, POD [5] ) имеют совместимое с С размещение в памяти: переменные-члены хранятся в порядке их объявления.

5

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

• Тип

int

занимает как минимум 16 битов.

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

• Размер

int

не равен ни 32 битам, ни какому-либо иному фиксированному размеру.

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

• Размещение класса в памяти не всегда приводит к размещению базового класса и членов

в указанном порядке.

• Между членами класса (даже если они являются POD) могут быть промежутки в целях выравнивания.

• 

offsetof

работает только для POD, но не для всех классов (хотя компилятор может и не сообщать об ошибках).

• Класс может иметь скрытые поля.

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

• Нельзя переносимо полагаться на конкретное размещение автоматических переменных в памяти или на направление роста стека.

• Указатели на функции могут иметь размер, отличный от размера указателя

void*

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

• Из-за вопросов выравнивания вы не можете записывать ни один объект по произвольному адресу в памяти.

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

Ссылки

[Dewhurst03] §95

92. Избегайте

reinterpret_cast

Резюме

Как гласит римская пословица, у лжи короткие ноги. Не пытайтесь использовать

reinterpret_cast

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

Обсуждение

Вспомните: Если вы лжете компилятору, он будет мстить (Генри Спенсер).

Преобразование

reinterpret_cast

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

Кроме того, реальность такова, что результат применения

reinterpret_cast

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

reinterpret_cast

зависит от реализации, так что вы даже не знаете точно, как именно он будет работать. Это очень ненадежное и непереносимое преобразование.

Исключения

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

reinterpret_cast

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

void*

вместо непосредственного использования

reinterpret_cast

, т.е. вместо кода