Александр
Мыслитель
(7569)
10 лет назад
Перед попыткой внесения if <100 - вносим, if =>100 - ругаемся. А лучше сразу проверять параметр при поступлении, ибо если получился заведомо невозможный/неправильный результат - это ошибка пользователя/программы/устройства, что недопустимо и об этом надо сообщить пользователю/программе, передающей параметры, которая этот момент тоже должна грамотно отработать.
Зачем писать говно, а потом разбираться, почему оно не работает? ) Строй подробный алгоритм с отработкой всех мыслимых и немыслимых ситуаций на бумаге.
Return0Профи (678)
10 лет назад
Весь парадокс ситуации именно в том, что это не будет ошибкой. Алгоритм рассчитывает x и y. Результат, который не входит в рамки массива не нужен, а значит если не обработать такое исключение, то это никак не повлияет на работоспособность программы. Разве это ошибка? По-моему, ошибка, это когда в результате недочёта теряется важная информация, а я хочу намеренно игнорировать данные, которые не актуальны - пусть себе теряются. Причина такого подхода - ускорение алгоритма. Ведь система сама знает, когда программа пытается записать в недоступный адрес, так зачем мне проверять условия всякие? Пусть просто не записывает в память, раз нельзя, и всё?
Hard Boy
Знаток
(374)
10 лет назад
Если сомневаешься, какой алгоритм лучше, то нужно проверять по времени выполнения.
Может лучше не допускать вероятность выхода за границы массива, если только он не динамический?
Return0Профи (678)
10 лет назад
Алгоритм вычисляет x и y в интервале от 0 до 65536 - это заведомо верный результат. И всё бы было хорошо, если бы я мог создать массив 65536 на 65536, но 4 гигабайта оперативной памяти выделять немного беспантово)
Прелесть в том, что мне не обязательно учитывать все результаты, достаточно только актуальные. В моём случае это: 0
Можно ли ускорить обработку ошибок записи, например так:
try
{
A[x][y]=0;
}
catch(...){}
Или try/catch не быстрее банального условия: if(x<100 && y<100)?
Есть ли другие способы?