program error;
{$APPTYPE CONSOLE}
{$mode objfpc}{$H+}
uses
{$IFDEF UNIX}{$IFDEF UseCThreads}
cthreads,
{$ENDIF}{$ENDIF}
Classes
{ you can add units after this };
{$R *.res}
const tab:array[0..9]of byte =(0,1,2,3,4,5,6,7,8,9);
var Count:Integer;
Function ReturnByte:Byte;
begin
If Count>9 then Count:=0;
Result:=Tab[Count];
Count:=Count+1;
end;
procedure WriteByte(S:String;a,b,c,d:Byte);
begin
WriteLn(S,a,' ',b,' ',c,' ',d);
end;
var a,b:Byte;
begin
Count:=0;
WriteLn (' Orginal ',tab[0],' ',Tab[1],' ',Tab[2],' ',Tab[3]);
WriteByte(' Bad Result ', ReturnByte,ReturnByte,ReturnByte,ReturnByte);
WriteLn (' Orginal ',tab[4],' ',Tab[5],' ',Tab[6],' ',Tab[7]);
a:= ReturnByte;
WriteByte(' Bad Result ', a,ReturnByte,ReturnByte,ReturnByte);
WriteLn (' Orginal ',tab[8],' ',Tab[9],' ',Tab[0],' ',Tab[1]);
a:= ReturnByte;
b:= ReturnByte;
WriteByte(' Good Result ', a,b,ReturnByte,ReturnByte);
Readln;
end.
na
http://wiki.freepascal.org/Code_Conversion_Guide#Order_of_parameter_evaluation
pisza ze
"Delphi gwarantuje, że wszystkie parametry są obliczane od lewej do prawej. FPC
nie zawiera takich gwarancji, a może wywołać parametry w dowolnej kolejności w
celu wytworzenia optymalnego kodu."
I tu problem bo w 99.99 % przypadków wywołań kolejność ma znaczenie .
--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl
> taki przykladowy program -- pokazuje że fpc w złej kolejnosci wywoluje funkcje
> zawarte w wywołaniu procedury .
Nie w "złej" tylko w "innej niż Dephi", co jest zresztą udokumentowane
w linku który podałeś:
> na
> http://wiki.freepascal.org/Code_Conversion_Guide#Order_of_parameter_evaluation
>
> pisza ze
> "Delphi gwarantuje, że wszystkie parametry są obliczane od lewej do prawej. FPC
> nie zawiera takich gwarancji, a może wywołać parametry w dowolnej kolejności w
> celu wytworzenia optymalnego kodu."
...i nawet jest przedstawiony powód dla którego kompilator może chcieć
reorder'nąć wywołania.
> I tu problem bo w 99.99 % przypadków wywołań kolejność ma znaczenie .
Nie, wbrew przeciwnie, w 99.(9)% przypadków poleganie na kolejności
wywołań ,podobnie jak w podanym przykładzie, to poleganie na
side-effect wywołania, a to jest bezwzględnie zła praktyka.
--
Pozdrawiam,
Łukasz 'Maly' Ostrowski. http://l3v.pl/
Jak to złej? Dokumentacja mówi, że kolejność jest niezdefiniowana. Więc
każda kombinacja jest równie prawidłowa.
> I tu problem bo w 99.99 % przypadków wywołań kolejność ma znaczenie .
Używając FPC jesteś zmuszony tak pisać kod, aby to znaczenie miało dokładnie
w 0,00%.
--
Azarien
to takiego efektu nie spodziewałem się po fpc .
Powszechnie uznaje się, że efekty uboczne w podprogramach to zła
praktyka programowania. Nie powinno się nigdy do tego dopuszczać. Jeżeli
już koniecznie musisz w jakimś szczególnym przypadku, to przecież można
sobie z tym łatwo poradzić.
Czy to taki wielki problem najpierw obliczyć wszystkie parametry w
odpowiedniej kolejności, przypisując obliczone wyniki zmiennym lokalnym,
a następnie wywołać odpowiedni podprogram przekazując te zmienne jako
parametry?
--
Pozdrawiam,
Grzegorz Skoczylas
http://gskoczylas.rekord.pl
----------------------------------------------
ale dlaczego w odpowiedniej kolejności? ta kolejność nie powinna mieć
znaczenia.
--
Azarien
IMHO kolega chce Ci powiedzie�, �e :
- Masz problem, bo �le napisa�e� program -
a nie :
- FPC �le oblicza parametry -
Wi�c kolejno�� nie jest wa�na : Napisz poprawnie program ....
nie uwierzysz ale tak mia�em -- i postanowi�em ze oczyszcze kod .
Pad�o na zmienne lokalne kt�re s� uzywane tylko przez chiwile , a przy okazji
zrobie funkcje parujaca stringa ( ReturnNumber ) .
Kod stan� si� czytelniejszy -- ale program nagle przesta� dzia�a� w oczekiwany
spos�b .
My�la�em ze jak w wywo�aniu procedury s� odwo�ania do funkcje to kompilator
elegancko wywo�uje te procedury ( w kolejno�ci jak w kodzie �r�d�owym )odk�ada
na stos wynik i wywo�uje procedure .
--
Wys�ano z serwisu OnetNiusy: http://niusy.onet.pl