Странная ошибка в for

← →
Pasha L © (2007-01-12 22:11) [0]

Здравствуйте. Такая вот странная задача:
вызываю
for y:=0 to 2 do for x:=0 to 9 do ar[y,x]:=0;
происходит что-то непонятное. Поставил брейкпоинт на заколовок первого цикла, и выясняется, что y принимает сначала значение не 0, а 3. x принимает значение 10. хоть размеры массива ar 0..2 0..9, ошибка не вылазит... потом, в следующем цикле, вообще вылазит ошибка, такая же странная, как эта проблема, так что мне кажется, они имеют одинаковые корни. Давно программирую, но с таким не сталкивался.

← →
zamtmn © (2007-01-12 22:23) [1]

>>Поставил брейкпоинт на заколовок первого цикла, и выясняется, что y принимает сначала значение не 0, а 3
на этой строчке y еще не отределен
>> потом, в следующем цикле, вообще вылазит ошибка
ar случайно не указатель?

← →
tesseract © (2007-01-12 22:24) [2]

> что y принимает сначала значение не 0, а 3.

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

← →
DrPass © (2007-01-12 22:31) [3]

> Возможно что-то с операциями с указателями в других областях
> кода.

В данном случае - скорее всего, просто у компилятора включена оптимизация

← →
sniknik © (2007-01-12 22:32) [4]

> что y принимает сначала значение не 0, а 3.
оптимизатор. цикл с проверкой на ноль после операции "легче" чем с дополнительной проверкой на конкретную цифру.

> вообще вылазит ошибка
а вот этого быть не должно, код правильный (та часть что сдесь) поведение стандартное.

← →
Almaz © (2007-01-12 22:38) [5]

> оптимизатор. цикл с проверкой на ноль после операции "легче"
> чем с дополнительной проверкой на конкретную цифру.

Учитывая тот факт, что переменные цикла используются внутри цикла, оптимизатор изменять порядок цикла не должен.

ИМХО, правильный ответ уже озвучили в первом посте - на первой строчке цикла при первом заходе переменные цикла еще не определены.

← →
sniknik © (2007-01-12 22:50) [6]

> переменные цикла еще не определены.
ага, и при первом заходе не определены и после неопределенно до 0 меняются... ;о))
проверь.

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

← →
sniknik © (2007-01-12 22:52) [7]

+
а вот если вот так ar[y, x]:= y*x; то уже используются

← →
Almaz © (2007-01-12 22:55) [8]

> переменные в данном случае не используются т.к. из индексирования
> массива они тоже выкинуты оптимизатором...

В этом случае он вообще не получил бы их значения, ИМХО.

← →
sniknik © (2007-01-12 23:01) [9]

> В этом случае он вообще не получил бы их значения, ИМХО.
почему это? для ограничения for они всеже используются... и так, как оптимальнее всего.

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

← →
sniknik © (2007-01-12 23:03) [10]

вот. чтобы вообще не "парится"
procedure TForm1.Button1Click(Sender: TObject); var ar: array[0..2, 0..9] of integer; x, y: integer; begin for y:= 0 to 2 do for x:= 0 to 9 do ar[y, x]:= 0; //y*x; end;

← →
Almaz © (2007-01-12 23:10) [11]

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

Не лень, конечно, но уверенность имеется ;) Проверил. При включенной оптимизации (D6), в исходном варианте (без умножения) получаю, что и ожидал:
Variable "X" inaccsessible here due to optimization.
Variable "Y" inaccsessible here due to optimization.

Что я и имел ввиду, говоря, что в этом случае он вообще не получил бы их значения

← →
sniknik © (2007-01-12 23:14) [12]

> Variable "X" inaccsessible here due to optimization.
> Variable "Y" inaccsessible here due to optimization.
а теперь 2 раза F8, и дойдешь до описываемой ситуации.

← →
Almaz © (2007-01-12 23:17) [13]

> теперь 2 раза F8, и дойдешь до описываемой ситуации.
Точно, ты прав. Не пришло мне в голову прокрутить отладчик дальше - смутило упоминание первой строки цикла ;)

Значит таки да - оптимизатор.

← →
Mr tray (2007-01-12 23:24) [14]

sniknik © (12.01.07 23:03) [10]
Я не такой ламер, как вам показалось, такой код я могу родить. Да, всё дело оказалось в оптимизаторе, если присваивать не к нулю, а, допучтим, к x+y, то всё в порядке. спасибо. А можно ли его отключить временно, к примеру, только на определенном куске кода?

← →
Pasha L © (2007-01-12 23:26) [15]

Mr tray и Pasha L это один и тот же человек.

← →
zamtmn © (2007-01-12 23:28) [16]

ох, забыл я что делфи "умеет" оптимизировать... каюсь
>> Да, всё дело оказалось в оптимизаторе, если присваивать не к нулю, а, допучтим, к x+y, то всё в порядке. спасибо. А можно ли его отключить временно, к примеру, только на определенном куске кода?
зачем его отключать, тут ошибка не изза него. заполнение массива всеравно иедет как ты задумал. хоть и показывает 3 и 10, заполняет от 0 до 2 и 0 до 9

← →
Almaz © (2007-01-12 23:29) [17]

> А можно ли его отключить временно, к примеру, только на
> определенном куске кода?

Можно. Директивой компилятора {$O-}, но не на любом участке кода, а только для выбранной процедуры или функции.

← →
sniknik © (2007-01-12 23:36) [18]

но для данного случая описанного в [0] это совершенно лишнее (блин, да я вообще сколько программирую никогда ее не отключал...), ошибка тут не в ней а в 17й строке, имхо.

>>но для данного случая описанного в [0] это совершенно лишнее (блин, да я вообще сколько программирую никогда ее не отключал...), ошибка тут не в ней а в 17й строке, имхо.
а явсегда работаю с выключеной. включаю только в релиз:). и судя по
>> если присваивать не к нулю, а, допучтим, к x+y, то всё в порядке.
ошибка не только в 17й, а ещеи фазы луны из [2]

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

> и судя по
>> если присваивать не к нулю, а, допучтим, к x+y, то всё в порядке.
> ошибка не только в 17й, а ещеи фазы луны из [2]
не фазы луны, а переменные стали используемыми (см. выше) для которых нужны (и оптимизатор дал их) реальные значения.

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

>>непонимаю я этого (имхо, это из разряда "пальцы погнуть")
никаких пальцев. просто зачем вспоминать при отладке что ты тут писал и додумывать во что это мог превратить компилятор. в [0] всё просто, но бывают случаи посложнее.
>>не фазы луны, а переменные стали используемыми (см. выше) для которых нужны (и оптимизатор дал их) реальные значения.
я имею ввиду не значение переменных, а то что хоть переменные исаользуются хоть нет, массив заполняется так как Pasha L задумал. не выходя за пределы
>>ошибка же вообще с показанным кодом напрямую не связана
тут добавить нечего

sniknik © (12.01.07 23:55) [21]
Да, оптимизатор не имеет ничего общего с последующей ошибкой. Буду копать дальше. Спасибо.

Хотя нет. В самом начале кода программы отрубил оптимизатор - ошибка не вылезает. Она была такая: выполнялся цикл в цикле, и вдруг, при некоторых значениях икса и игрика, игрик принимал абсолютно непонятно откуда берущееся значение, очень большое в сравнении с теми, с которыми я оперирую, и, так как с помощью игрика я ссылался на элнменты массива (ar[y,x]), выползала ошибка. Причем, я долго до этого отлаживал и дополнял программу, этот кусок порграммы выполнялся без проблем.

>> так как с помощью игрика я ссылался на элнменты массива (ar[y,x])
с оптимизацией x,y не учавствуют в обращении к массиву. это просто счетчики цикла. гляди cpu window
>> вдруг, при некоторых значениях икса и игрика, игрик принимал абсолютно непонятно откуда берущееся значение
такого небывает. может ты х или у используешь за пределами цикла? посмотри варнинги. копай, копай:)

Pasha L © (13.01.07 00:20) [24]
ты не домыслы свои высказывай, а давай конкретное, код, текст ошибки.

> игрик принимал абсолютно непонятно откуда берущееся значение
все понятно, что откуда берется, если конечно гадать не приходится.

> так как с помощью игрика я ссылался на элнменты массива
в ПОКАЗАННОМ КОДЕ (сколько раз одно и тоже повторять?) ты не ссылался на с помощью игрека на элементы массива, в показанном, игрек существует только для ограничения цикла, на элементы массива (вернее адрес) указывает какойто регистр, подставленный оптимизатором. т.е. если там и вылезло в y бешенное значение(вот только с чего бы это? точно фазы луны. регистр оборотень попался...) то это количество итераций циклу добавит, и хотя и вызовет ошибку, но не сразу и не от ссылки, а от повторов когда ссылка перевалит через границы массива и "уйдет" в код. либо в защищенную область памяти.

Странная ошибка в for Найти похожие ветки