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

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

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

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

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

[Dewhurst03] §95

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

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

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

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

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

T1* p1 = ... ;

T2* p2 = reinterpret_cast(p1);

лучше писать

T1* p1 = ...;

void* pV = p1;

T2* p2 = static_cast(pV);

[С++03] §5.2.10(3) • [Dewhurst03] §39 • [Stroustrup00] §5.6

К указателям на динамические объекты не следует применять преобразование 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 To checked_cast(From* from) {

assert(dynamic_cast(from) ==

static_cast(from) && "checked_cast failed" );

return static_cast(from);

}

template To checked_cast(From& from) {

typedef tr1::remove_reference::type* ToPtr; // [C++TR104]

assert(dynamic_cast(&from) ==

static_cast(&from) && "checked_cast failed");

return static_cast(from);

}

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

[Dewhurst03] §29, §35, §41 • [Meyers97] §39 • [Stroustrup00] §13.6.2 • [Sutter00] §44

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

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

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