выход индекса за пределы дозволеного, философия Опции Подписка на тему Сообщить другу Версия для печати Скачать тему Подписка на этот форум Режимы отображения Переключить на: Древовидный Переключить на: Стандартный Линейный

[Litkevich Yuriy]

у меня возник вопрос - "а хорошо ли программе падать?"

Есть перегруженный оператор [], в него передаётся индекс, и внутри оператора сделан assert на случай выхода индекса за границы разрешённого диаппазона.

Вроде так многие делают. Но правильно ли это?

Может правильнее поступать как-то иначе?

[DIMEDROLL]

Может правильнее поступать как-то иначе?

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

Добавлено:
ИМХО ассерт - лучший друг программиста, ассертить можно все на что опираешься(напрмер, "эта переменная не должна быть ниже нуля"): входящие данные, выходящие данные, указатели, результаты connect, а уж тем более индексацию массивов... Зачастую, с помощью ассертов я находил такие баги что с дебаггером искал бы не один час. И бывало что с дебаггером сидел пол для, что бы обнаружить запись на 1 значение дальше конца массива.
Но не надо забывать о чистоте кода, если все и везде ассертить выйдет каша в коде,

Сообщение отредактировал DIMEDROLL - 21.4.2010, 12:15

[Litkevich Yuriy]

вообще я всюду стараюсь использовать не просто int, а собственный тип данных, например так:

enum MyType{
    Val_1,
    Val_2
}
setType(MyType value);
MyType type();

это позволяет при программировании защитится от случайных входных значений. Но с индексами так не получается работать. И к сожалению в С\С++ нет типа диаппазона

Я вроде пытаюсь себя дисциплинировать такими вещами:

if (i < foo.size()) var = foo[i];
else do_anything();

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

[BRE]

IMHO, в операторе [] выход за пределы контейнера это по любому ошибка в коде программы. Ввод пользователя должен быть проверен еще до входа в этот метод. Такие ошибки должны отслеживаться еще на этапе отладки. Т.е. assert вполне удовлетворяет этим условиям, к тому же в релизе мы избавляемся от кода проверки.
Хотя, для особо дружественных программ можно использовать исключение, и при его возникновении сообщать пользователю, что произошла внутренняя ошибка # ... и ему нужно связаться с разработчиками.

[Litkevich Yuriy]

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

И Ассерт, здесь не информативен, т.к. в релизе кроме как в консоль он ничего не пишет, а её никто не видит. Просто "Бац и программа вылетела"

[BRE]

Все внешние данные, не важно откуда они приходят, должны быть проверенны еще до оператора []. По любому.
assert в этом операторе, только для программиста и говорит о том, что он где-то выше забыл проверить индекс.

[Tonal]

...И к сожалению в С\С++ нет типа диаппазона...

boost::range

[Iron Bug]

IMHO, в операторе [] выход за пределы контейнера это по любому ошибка в коде программы. Ввод пользователя должен быть проверен еще до входа в этот метод. Такие ошибки должны отслеживаться еще на этапе отладки. Т.е. assert вполне удовлетворяет этим условиям, к тому же в релизе мы избавляемся от кода проверки.
Хотя, для особо дружественных программ можно использовать исключение, и при его возникновении сообщать пользователю, что произошла внутренняя ошибка # ... и ему нужно связаться с разработчиками.

вот тоже так думаю. и "особая дружественность" тут ни при чём. любой эксепшн должен обрабатываться и не приводить к обрушению программы. это ненормальное программирование, если программист позволяет своей программе просто так взять и рухнуть, возможно, потеряв данные и запортив работу пользователя. вообще, неважно, даже если у программы нет пользователя и она работает в сервисном режиме - то тогда проблема становится ещё более актуальна: при неожиданном сбое не упасть, записать инфу в лог и продолжить работу.

...И к сожалению в С\С++ нет типа диаппазона...

boost::range

да, тоже вариант: использование более надёжных объектов для хранения данных. у буста есть структуры для хранения произвольных данных, для обозначения "не числа" (т.е. переменная может содержать информацию, что её значение не валидно) и т.п. так что осваивайте и используйте на здоровье.

Сообщение отредактировал Iron Bug - 22.4.2010, 8:32

[BRE]

вот тоже так думаю. и "особая дружественность" тут ни при чём. любой эксепшн должен обрабатываться и не приводить к обрушению программы. это ненормальное программирование, если программист позволяет своей программе просто так взять и рухнуть, возможно, потеряв данные и запортив работу пользователя. вообще, неважно, даже если у программы нет пользователя и она работает в сервисном режиме - то тогда проблема становится ещё более актуальна: при неожиданном сбое не упасть, записать инфу в лог и продолжить работу.

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

[Litkevich Yuriy]

Другими словами Assert внутри оператора [], это вполне хорошо?
Например в сравнении с его отсутствием (программа тоже может упасть, но не сразу)

[Andrewshkovskii]

Я так понял что BRE предлагает использовать проверку значения индекса на вхождение в range коллекции не в операторе [], а где-то выше по уровню реализации.

[Litkevich Yuriy]

это-то понятно. Я для случая, если всё таки прозивал, то внутри оператора делать ли assert или нет.
assert гарантировано завалит приложение, выдав на консоль номер строки и файла, в котором он сработал.
А вот без него работа программы может продолжится (случалось)

[Andrewshkovskii]

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

[BRE]

это-то понятно. Я для случая, если всё таки прозивал, то внутри оператора делать ли assert или нет.
assert гарантировано завалит приложение, выдав на консоль номер строки и файла, в котором он сработал.
А вот без него работа программы может продолжится (случалось)

assert лучший друг программиста.
IMHO, использовать обязательно.

[Iron Bug]

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

[Litkevich Yuriy]

а так, честно ловить экспшны

а к стати какое-то конкретное исключение возникает при обращении в не разрешённую область памяти?

[Andrewshkovskii]

memory access violation ?

вот тут обсуждалось

Сообщение отредактировал Andrewshkovskii - 22.4.2010, 13:46

[Litkevich Yuriy]

memory access violation ?

похоже что так

[Tonal]

В Винде возникает системное исключение STATUS_ACCESS_VIOLATION как правильно указал Andrewshkovskii.
Некоторые компиляторы в некоторых режимах умеют переводить системные исключения винды в исключения С++.
Например MSVC с нужной опцией или багланд в режиме совместимости с делфой.

В унихе возникает системный сигнал SIGSEGV.

Читай, например, в википедии.

[Влад]

имхо ассерты только для дебага. ну, в крайнем случае, можно их оставить на время приёмо-отладочных работ. но не в рабочей версии.

Хм, так вроде бы assert() и имеет смысл только в дебажной версии; в release версии он раскрывается в "ничто" и исключается компилятором. Нет? А заказчику всяко поставляется Release сборка, но не Debug.
Что же до "приёмо-отладочных работ", то (имхо) отладка ПО и приемо-сдаточные испытания (ПСИ) - это совершенно различные этапы работ, и второй может начинаться только после полного окончания первого.

[Litkevich Yuriy]

в release версии он раскрывается в "ничто" и исключается компилятором. Нет?

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

[BRE]

в release версии он раскрывается в "ничто" и исключается компилятором. Нет?

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

Собирай релиз с QT_NO_DEBUG, не будет.

[AD]

в release версии он раскрывается в "ничто" и исключается компилятором. Нет?

Q_ASSERT в релизной работает.

Вы о разных assertax говорите.

[Litkevich Yuriy]

Собирай релиз с QT_NO_DEBUG, не будет.

лучше пусть будет