1. Совместимость. Люди использовали индексирование без проверки выхода за пределы допустимого диапазона задолго до того, как в языке C++ появились исключения.
2. Эффективность. Можно создать оператор с проверкой выхода за пределы допустимого диапазона на основе оптимально эффективного оператора индексирования без такой проверки, но невозможно создать оператор индексирования без проверки выхода за пределы допустимого диапазона, обладающий оптимальным быстродействием, на основе оператора доступа, выполняющего такую проверку.
3. Ограничения. В некоторых средах исключения не допускаются.
4. Необязательная проверка. На самом деле стандарт не
утверждает, что вы не можете проверить диапазон в классе
vector
, поэтому, если хотите выполнить проверку, можете ее реализовать.
19.4.1.1. Совместимость
Люди очень не любят переделывать старый код. Например, если вы написали миллионы строк кода, то было бы очень дорого переделывать его полностью, чтобы корректно использовать исключения. Мы могли бы сказать, что после такой переделки код станет лучше, но не станем этого делать, поскольку не одобряем излишние затраты времени и денег. Более того, люди, занимающиеся сопровождением существующего кода, обычно утверждают, что в принципе код без проверки небезопасен, но их конкретная программа была протестирована и используется уже многие годы, так что в ней уже выявлены все ошибки. К этим аргументам можно относиться скептически, но в каждом конкретном случае следует принимать взвешенное решение. Естественно, нет никаких программ, которые использовали стандартный класс
vector
до того, как он появился в языке C++, но существуют миллионы строк кода, в которых используются очень похожие классы, но без исключений. Большинство этих программ впоследствии было переделано с учетом стандарта.
19.4.1.2. Эффективность
Да, проверка выхода за пределы диапазона в экстремальных случаях, таких как буферы сетевых интерфейсов и матрицы в высокопроизводительных научных вычислениях, может оказаться слишком сложной. Однако стоимость проверки выхода за пределы допустимого диапазона редко учитывается при обычных вычислениях, которые выполняются в большинстве случаев. Таким образом, мы рекомендуем при малейшей возможности использовать проверку выхода за пределы допустимого диапазона в классе
vector
.
19.4.1.3. Ограничения
В этом пункте, как и в предыдущем, аргументы нельзя считать универсальными. Несмотря на то что они разделяются практически всеми программистами и не могут быть просто отброшены, если вы начинаете писать новую программу в среде, не связанной с вычислениями в реальном времени (см. раздел 25.2.1), то используйте обработку ошибок с помощью исключений и векторы с проверкой выхода за пределы допустимого диапазона.
19.4.1.4. Необязательная проверка
Стандарт ISO C++ утверждает, что выход за пределы допустимого диапазона вектора не имеет гарантированной семантики, поэтому его следует избегать. В соответствии со стандартом при попытке выхода за пределы допустимого диапазона следует генерировать исключение. Следовательно, если вы хотите, чтобы класс
vector
генерировал исключения и не создавал проблем, связанных с первыми тремя аргументами, в конкретном приложении следует использовать класс
vector
с проверкой выхода за пределы допустимого диапазона. Именно этого принципа мы придерживаемся в нашей книге.
Короче говоря, реальная программа может оказаться сложнее, чем хотелось бы, но всегда есть возможность скопировать готовые решения.
19.4.2. Признание: макрос
Как и наш класс vector, большинство реализаций стандартного класса
vector
не гарантирует проверку выхода за пределы допустимого диапазона с помощью оператора индексирования (
[]
), а вместо этого содержит функцию
at
, выполняющую
такую проверку. В каком же месте нашей программы возникают исключения
std::out_of_range
? По существу, мы выбрали вариант 4 из раздела 19.4.1: реализация класса
vector
не обязана проверять выход за пределы допустимого диапазона с помощью оператора
[]
, но ей не запрещено делать это иным способом, и мы решили воспользоваться этой возможностью. Однако в нашей отладочной версии под названием
Vector
, разрабатывая код, мы реализовали проверку в операторе
[]
. Это позволяет сократить время отладки за счет небольшой потери производительности программы.
struct Range_error:out_of_range { // подробное сообщение
Vector(size_type n, const T& v):std::vector<T>(n,v) {}
T& operator[](size_type int i) // rather than return at(i);
{
if (i<0||this–>size<=i) throw Range_error(i);
return std::vector<T>::operator[](i);
}
const T& operator[](size_type int i) const
{
if (i<0||this–>size<=i) throw Range_error(i);
return std::vector<T>::operator[](i);
}
};
Мы используем класс
Range_error
, чтобы облегчить отладку операции индексирования. Оператор
typedef
вводит удобный синоним, который подробно описан в разделе 20.5.
Класс
Vector
очень простой, возможно, слишком простой, но он полезен для отладки нетривиальных программ. В качестве альтернативы нам пришлось бы использовать реализацию стандартного класса
vector
, предусматривающую систематическую проверку, — возможно, именно это нам и следовало сделать; у нас нет информации, насколько строгой является проверка, предусмотренная вашим компилятором и библиотекой (поскольку это выходит за рамки стандарта).
В заголовке
std_lib_facilities.h
мы используем ужасный трюк (макроподстановку), указывая, что слово vector означает
Vector
.
// отвратительный макрос, чтобы получить вектор
// с проверкой выхода за пределы допустимого диапазона
#define vector Vector
Это значит, что там, где вы написали слово
vector
, компилятор увидит слово
Vector
. Этот трюк ужасен тем, что вы видите не тот код, который видит компилятор. В реальных программах макросы являются источником довольно большого количества запутанных ошибок (разделы 27.8 и A.17).