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

Резюме

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

Обсуждение

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

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

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

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

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

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

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

Ссылки

[Boost] • [Cowan01] • [Murray93] §2.6 • [Sutter04] §2-3 • [Tsai01]

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

Резюме

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

Обсуждение

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

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

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

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