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

1. Совместимость. Люди использовали индексирование без проверки выхода за пределы допустимого диапазона задолго до того, как в языке C++ появились исключения.

2. Эффективность. Можно создать оператор с проверкой выхода за пределы допустимого диапазона на основе оптимально эффективного оператора индексирования без такой проверки, но невозможно создать оператор индексирования без проверки выхода за пределы допустимого диапазона, обладающий оптимальным быстродействием, на основе оператора доступа, выполняющего такую проверку.

3. Ограничения. В некоторых средах исключения не допускаются.

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

, поэтому, если хотите выполнить проверку, можете ее реализовать.

Люди очень не любят переделывать старый код. Например, если вы написали миллионы строк кода, то было бы очень дорого переделывать его полностью, чтобы корректно использовать исключения. Мы могли бы сказать, что после такой переделки код станет лучше, но не станем этого делать, поскольку не одобряем излишние затраты времени и денег. Более того, люди, занимающиеся сопровождением существующего кода, обычно утверждают, что в принципе код без проверки небезопасен, но их конкретная программа была протестирована и используется уже многие годы, так что в ней уже выявлены все ошибки. К этим аргументам можно относиться скептически, но в каждом конкретном случае следует принимать взвешенное решение. Естественно, нет никаких программ, которые использовали стандартный класс

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

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

.

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

Стандарт ISO C++ утверждает, что выход за пределы допустимого диапазона вектора не имеет гарантированной семантики, поэтому его следует избегать. В соответствии со стандартом при попытке выхода за пределы допустимого диапазона следует генерировать исключение. Следовательно, если вы хотите, чтобы класс

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

Короче говоря, реальная программа может оказаться сложнее, чем хотелось бы, но всегда есть возможность скопировать готовые решения.

Как и наш класс vector, большинство реализаций стандартного класса

не гарантирует проверку выхода за пределы допустимого диапазона с помощью оператора индексирования (), а вместо этого содержит функцию , выполняющую такую проверку. В каком же месте нашей программы возникают исключения ? По существу, мы выбрали вариант 4 из раздела 19.4.1: реализация класса не обязана проверять выход за пределы допустимого диапазона с помощью оператора , но ей не запрещено делать это иным способом, и мы решили воспользоваться этой возможностью. Однако в нашей отладочной версии под названием , разрабатывая код, мы реализовали проверку в операторе . Это позволяет сократить время отладки за счет небольшой потери производительности программы.