как ответить на вопрос ! Опции

[лена]

program R;
  var a,i:real;
  procedure P1;
   var b :real;
       procedure P2;
            var x,i :real;
              begin
               i:=2
       begin
       end{P2};
i:=99;P2;
writeln (i) {99}
end{P1};

function F :real;
var z :real;
 begin
     i:=0; F:=i
 end{F};

begin
P1;
writeln (i);{99}
writeln (i+F); {99+0=0(?)}
writeln (F+i);  {0+0=0}
end {R}.

В приведенном выше примере побочный эффект выражается в том , что нарушается одно из правил сложения «при перемени мест слагаемых сумма не меняется» : i+F=99, но F+i =0.
Рассмотрим причины возникновения такой ситуации и познакомимся с одной из парадоксов версии Турбо –Паскаля.
Проведем анализ алгоритма главной программы R.
При обращении к процедуре Р1 переменная  I принимает значения 99.
Причем при обращении к внутренней процедуре Р2 (имеющей локальную переменную i) значение I не меняется , согласно сформулированным правилам локализации.
Функция F всегда возвращает значение , равное нулю и i=0.
Поэтому, так как в первом случае переменная i  является первым слагаемым, то : i+F=99.
Во втором арифметическом выражении вначале происходит обращение к функции  F, после которого результат функции и переменная  i  равны нулю, поэтому и сумма их равна нулю: F+i =0.
но при использовании версии Турбо-Паскаль , результат в обоих случаях, вопреки всем правилам , будет равен нулю. Например, если сделать предположение, что все дело в приоритете операций ( выполнение арифметического выражения всегда начинается с вычисления функций),  то эксперименты в этом направлении ничего не изменят : тот же нулевой результат.

    Вопрос = Почему в турбо паскале проявляется этот побочный эффект?  

[SKVOZNJAK]

      begin
               i:=2
       begin
       end{P2};
i:=99;P2;

Что это за конструкция такая кривая  ;) Чему ж тогда удивляться что и работает она криво? Для нормальной работы проги соотношение операторов BEGIN END должно быть сбалансировано.  Не проверял, проглотит-ли твою прогу компилятор. У меня тоже был случай - фраза на русском языке(забыл какая) в комментариях воспринималась как директива компилятора. Фразу убрал, и всё пошло нормально. Задача прогера в том, чтобы интуитивно обходить такие дыры, а хакера - чтобы находить их :D

[Shadow]

ответ чисто интуитивен
т.к. компиляторы пишут люди, а людям свойственно ошибаться
то компиляторы тоже ошибаются
-=-=-=
на этот вопрос легче ответить путем ТРАССИРОВАНИЯ этой проги
черех отладчик в ASM коде

ASSEMBLER тут реальные ответы более понятно

-=-=-=-
тогда сразу все станет на свои места
-=-=-=

[SKVOZNJAK]

-=-=-=
на этот вопрос легче ответить путем ТРАССИРОВАНИЯ этой проги
черех отладчик в ASM коде

Кто ж спорит, что так оно легче ;) Хотя это чисто индивидуально. Когда-то спросонку я переводил человеческую речь в только что изобретённый диалект асмы, глядел на виртуальный экран. Под взглядом строчки укрупнялись, и смысл проги (будили меня!) становился понятен. Наконец в программе обнаружилась дыра (из примера видно, что и от прогера тоже кое-что зависит ;) ) и я с радостью одал её на выполнение - переместился в сидячее положение и заснул снова ! Вот только потом асма куда-то улетучилась

[trminator]

Точно такой же вопрос уже встречался на этом форуме: http://forum.pascalnet.ru/?board=zd;actio...;num=1070823345

[AlaRic]

Модератор внимательнее!