gcc — C ++: векторные границы

Книга немного расплывчата. Это не столько «ошибка времени выполнения», сколько неопределенное поведение который проявляется во время выполнения. Это означает, что может произойти все, что угодно. Но ошибка строго с вы, не с выполнением программы, и фактически невозможно и даже неразумно говорить о выполнении программы с неопределенным поведением.

В C ++ нет ничего, что защищало бы вас от ошибок программирования, в отличие от Java.

Как говорит @sftrabbit, std::vector имеет альтернативный интерфейс, .at(), которая всегда дает правильную программу (хотя она может генерировать исключения) и, следовательно, ту, о которой можно рассуждать.

Позвольте мне повторить это на примере, потому что я считаю, что это важный фундаментальный аспект C ++. Предположим, мы читаем целое число от пользователя:

int read_int()
{
std::cout << "Please enter a number: ";
int n;
return (std::cin >> n) ? n : 18;
}

Теперь рассмотрим следующие три программы:

Опасный Правильность этой программы зависит от ввода пользователя! Это не обязательно некорректный, но это небезопасный (до точки, где я бы назвал это сломанным).

int main()
{
int n = read_int();
int k = read_int();
std::vector<int> v(n);
return v[k];
}

Безоговорочно правильно: Независимо от того, что вводит пользователь, мы знаем, как ведет себя эта программа.

int main() try
{
int n = read_int();
int k = read_int();
std::vector<int> v(n);
return v.at(k);
}
catch (...)
{
return 0;
}

Нормальный: Выше версия с .at() неловко Лучше проверить и оставить отзыв. Поскольку мы выполняем динамическую проверку, неконтролируемый векторный доступ гарантированно будет работать нормально.

int main()
{
int n = read_int();

if (n <= 0) { std::cout << "Bad container size!\n"; return 0; }

int k = read_int();

if (k < 0 || k >= n)  { std::cout << "Bad index!\n"; return 0; }

std::vector<int> v(n);
return v[k];
}

(Мы игнорируем возможность того, что конструкция вектора может вызвать собственное исключение.)

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

Если бы я хотел быть шутливым, я бы сравнил этот подход с Python, который позволяет писать невероятно короткая а также правильный программы, без какой-либо написанной пользователем обработки ошибок вообще. Обратная сторона в том, что любая попытка использовать такую ​​программу, которая отклоняется только немного из того, что задумал программист, у вас останется неконкретное, трудно читаемое исключение и трассировка стека и небольшое руководство о том, что вы должны были сделать лучше. Вы не обязаны писать какую-либо обработку ошибок, и часто никакая обработка ошибок не заканчивается записью. (Я не могу полностью противопоставить C ++ Java безопасный, Я еще не видел короткая Java программа.)</ rantmode>