Czasami wydaje się że program jest poprawny, choć jest błędny...
Mariusz Marszałkowski
czasami
kod programu jest na tyle prosty, że jesteśmy pewni iż jest poprawny,
mimo
pewności testujemy program i testy potwierdzają że jest poprawny.
Jednak tak
naprawdę w bardziej skomplikowanych sytuacjach, albo dla rzadkich
kombinacji
danych wejściowych, program nie zadziała, pomimo naszego
doświadczenia,
pomimo pewności, pomimo prostoty kodu i nawet pomimo testów tak
naprawdę
kod zawiera błąd. To sytuacja która każdemu programiście, bez względu
na jego
talent i doświadczenie, czasami się przydarza.
Ale czy może zdarzyć się odwrotnie? Czy program z błędami które
dostrzegamy (albo
w końcu dostrzegamy) może działać poprawnie? Do niedawna nigdy mi się
to nie
przytrafiło...
Przedwczoraj testowałem pewien kod. Jeden program pobierał dane
wejściowe, przez
kilka minut wykonywał obliczenia, a wyniki obliczeń wysyłał do innego
programu w
celu potwierdzenia poprawności. Z powodu wymagań protokołu, ten inny
program
jeszcze raz z powrotem wysyłał wyniki do mojego, a mój jeszcze raz
sprawdzał czy
doszedł do takich samych wyników.
Mniej więcej wyglądało to tak, mamy dwa programy o nazwach A i B.
A dostaje dane wejściowe
B dostaje dane wejściowe
A wykonuje obliczenia
B wykonuje obliczenia
A wysyła wyniki obliczeń do B
B weryfikuje czy wyniki są identyczne
B wysyła do A
A robi tylko(!) strcmp swojej kopii wyników
Błąd polegał na tym, że zamiast if( strcmp(x,y) == 0 ) miałem if
( strcmp(x,y) ).
Cała heca polega na tym, że to działało! Przeszło wiele testów.
Program
był rozbudowywany i po kilku rozbudowach ten fragment kodu cały czas
działał
jak najbardziej poprawnie. Dopiero po którejś z kolejnych modyfikacji
test
od razu na starcie się wyłożył. Wyłożył się właśnie na tym banalnym
fragmencie z
if( strcmp ) który od dawna działał, choć nie miał prawa działać.
Żeby było mało, godzinę temu znalazłem w programie analogiczną
sytuację.
Banalny błąd, zamiast "return true", wpisałem "return false".
Instrukcja w
testach programu była wykonywana miliony razy i działała poprawnie
chociaż
nie miała prawa zadziałać ani razu.
Totalnie zgłupiałem. Zastanawiałem się nad błędem kompilatora, ale to
nie
jest prawdopodobne. Zastanawiałem się czy to może być spowodowane
specyficznymi
instrukcjami niedostępnymi na danym procesorze, ale w takich
sytuacjach
raczej cały program by się rozsypał. Możliwa jest także sytuacja że
dwa
błędy wzajemnie się znosiły, ale co za błąd może znosić "return false"
i
zamieniać na "return true"? Nie pojmuję tego.
Pozdrawiam
Paweł Kierski
[...]
> Możliwa jest także sytuacja że
> dwa
> błędy wzajemnie się znosiły, ale co za błąd może znosić "return false"
> i
> zamieniać na "return true"? Nie pojmuję tego.
Przykro mi, że nie pojmujesz własnego kodu... ale to się zdarza 8-)
Najwyraźniej wynik tej funkcji miał nieduże przełożenie na działanie
programu w większości przypadków.
--
Paweł Kierski
ne...@pkierski.net
fir
> czasami
> kod programu jest na tyle prosty, �e jeste�my pewni i� jest poprawny,
> mimo
> pewno�ci testujemy program i testy potwierdzaj� �e jest poprawny.
> Jednak tak
> naprawdďż˝ w bardziej skomplikowanych sytuacjach, albo dla rzadkich
> kombinacji
> danych wej�ciowych, program nie zadzia�a, pomimo naszego
> do�wiadczenia,
> pomimo pewno�ci, pomimo prostoty kodu i nawet pomimo test�w tak
> naprawdďż˝
> kod zawiera b��d. To sytuacja kt�ra ka�demu programi�cie, bez wzgl�du
> na jego
> talent i do�wiadczenie, czasami si� przydarza.
>
> Ale czy mo�e zdarzy� si� odwrotnie? Czy program z b��dami kt�re
> dostrzegamy (albo
> w ko�cu dostrzegamy) mo�e dzia�a� poprawnie? Do niedawna nigdy mi si�
> to nie
> przytrafi�o...
>
> Przedwczoraj testowa�em pewien kod. Jeden program pobiera� dane
> wej�ciowe, przez
> kilka minut wykonywa� obliczenia, a wyniki oblicze� wysy�a� do innego
> programu w
> celu potwierdzenia poprawno�ci. Z powodu wymaga� protoko�u, ten inny
> program
> jeszcze raz z powrotem wysy�a� wyniki do mojego, a m�j jeszcze raz
> sprawdzaďż˝ czy
> doszed� do takich samych wynik�w.
>
> Mniej wi�cej wygl�da�o to tak, mamy dwa programy o nazwach A i B.
> A dostaje dane wej�ciowe
> B dostaje dane wej�ciowe
> A wykonuje obliczenia
> B wykonuje obliczenia
> B weryfikuje czy wyniki sďż˝ identyczne
> B wysy�a do A
> A robi tylko(!) strcmp swojej kopii wynik�w
>
> B��d polega� na tym, �e zamiast if( strcmp(x,y) == 0 ) mia�em if
> ( strcmp(x,y) ).
> Ca�a heca polega na tym, �e to dzia�a�o! Przesz�o wiele test�w.
> Program
> by� rozbudowywany i po kilku rozbudowach ten fragment kodu ca�y czas
> dzia�a�
> jak najbardziej poprawnie. Dopiero po kt�rej� z kolejnych modyfikacji
> test
> od razu na starcie si� wy�o�y�. Wy�o�y� si� w�a�nie na tym banalnym
> fragmencie z
> if( strcmp ) kt�ry od dawna dzia�a�, cho� nie mia� prawa dzia�a�.
>
> �eby by�o ma�o, godzin� temu znalaz�em w programie analogiczn�
> sytuacjďż˝.
> Banalny b��d, zamiast "return true", wpisa�em "return false".
> Instrukcja w
> testach programu by�a wykonywana miliony razy i dzia�a�a poprawnie
> chociaďż˝
> nie mia�a prawa zadzia�a� ani razu.
>
> Totalnie zg�upia�em. Zastanawia�em si� nad b��dem kompilatora, ale to
> nie
> jest prawdopodobne. Zastanawia�em si� czy to mo�e by� spowodowane
> specyficznymi
> instrukcjami niedost�pnymi na danym procesorze, ale w takich
> sytuacjach
> raczej ca�y program by si� rozsypa�. Mo�liwa jest tak�e sytuacja �e
> dwa
> b��dy wzajemnie si� znosi�y, ale co za b��d mo�e znosi� "return false"
> i
> zamieniaďż˝ na "return true"? Nie pojmujďż˝ tego.
>
> Pozdrawiam
musisz przyjrzec sie, zdebugowac i zobaczyc co sie naprawde dzieje
czasem kompilatory maja glupie dziury, o ile pamietam (a chyba tak)
w borland builderze 5 np mozesz w funkcji
np
int f()
{
//...kode
}
int a=f();
nie zwrocic wartosci (po prostu nie napisac return) a bb5
wrzuci ci tam jakas wartosc i nawet nie zglosi zadnego bledu
trudne do uwierzenia ale sam sie kiedys przekonalem ze tak jest
gdy dzialy sie dziwne rzeczy
fir
--
Wys�ano z serwisu OnetNiusy: http://niusy.onet.pl
Jacek Czerwinski
> Ale czy mo�e zdarzy� si� odwrotnie? Czy program z b��dami kt�re
> dostrzegamy (albo
> w ko�cu dostrzegamy) mo�e dzia�a� poprawnie? Do niedawna nigdy mi si�
> to nie
> przytrafi�o...
Oj to bardzo istotne pytanie. Trzeba przyj��, �e znaczny procent b��d�w
nie jest ujawniony. Literatura niezawodno�ciowa odr�nia b��d tkwi�cy
sobie w programie (cho�by 10 lat), a przypadek ujawnienia go.
Kiedy� by� eksperyment, zesp� A testowa� program, ujawni� N b�ed�w,
zesp� B ujawni� M b��d�w, w tym K powtarzaj�cych si� z zespo�em A. Na
tej podstawie mo�na si� statystycznie doliczy�, �e jest tam tyle a tyle
nieznanych b��d�w. By�o to bardzo du�o (K bardzo ma�e).
Statystycznie si� dochodzi, �e je�li w module programowym A znaleziono
ma�o b��d�w, w module B wi�cej, to ... popularne odczucie m�wi, �e B
jest ju� teraz lepiej dotestowany. Wzory m�wi�, �e prawdopodobie�stwo
nieznalezionego b��du jest wi�ksze w A. Oczywi�cie to uproszczenie,
zak�ada m.in, jednakowa intensywno�c test�w.
Na poziomie psychologii, programista ma miec zakodowane w g�owie, �e
b��dy, w tym b��dy w jego kodzie b�d� zawsze (a wtedy ma szanse je
dostrzec). Jesli temu zaprzecza, jego przydatno�� jest w�tpliwa.
St�d (moja subiektywna ocena) takie zjawisko, �e statystyczny dobry
programista jest �rednio bardziej pesymistycznym charakterem ni� np.
statystyczny pracownik marketingu czy akwizycji.
Wypowiadaj�c si� w nieco luzniejszej konwencji, jest takie przys�owie,
�e b��dy daj� si� wykry� gdy jest ich nieparzysta ilo�� (w podtek�cie
sugestia, �e b��dy sie kompensuj�). Po�rednio Tw�j post to potwierdza.
Klasyka to w jednym miejscu przejechanie o +1 a w drugim (�wiadome lub
podswiadome) skompensowanie o -1. Kod jak piszesz dzia�a, cho�
specyfikacje (funkcji , bufor�w itd) s� zaimplementowanie b��dnie i w
innych okolicznosciach siďż˝ moze ujawniďż˝.
W zupe�nie komercyjnym kodzie, m�j 'ukochany' Borland ma Stringa gdzie
literki licz� si� od 1 (do�� rzadkie w C - ale dobra, mo�na si�
przeuczyďż˝), ale jest niekonsekwencja: Substring od 0 nie daje exception
jak powinien, dzia�a tak samo jak od 1-ki. Dla mnie debilne i chyba
�wiadome kompensowanie b��du.
Oczywi�cie s� j�zyki, metodyki pracy, OO, rozw�j technologiczny itd
kt�re polepszaj� niezawodno��, ale to zawsze jest gdzie� pomi�dzy (0..1)
Tomasz Kaczanowski
> Na poziomie psychologii, programista ma miec zakodowane w g�owie, �e
> b��dy, w tym b��dy w jego kodzie b�d� zawsze (a wtedy ma szanse je
> dostrzec). Jesli temu zaprzecza, jego przydatno�� jest w�tpliwa.
> St�d (moja subiektywna ocena) takie zjawisko, �e statystyczny dobry
> programista jest �rednio bardziej pesymistycznym charakterem ni� np.
> statystyczny pracownik marketingu czy akwizycji.
Zgadza si�. Dodatkowo - nale�y powiedzie�, �e programista jest
najgorszym z mo�liwych tester�w w�asnego kodu. Bo automatycznie sprawdza
przypadki, na kt�re si� zabezpieczy� i g��wnie sprawdza, czy
zabezpieczenia, kt�re w kodzie wstawi� zadzia�aj� poprawnie.
--
Kaczus
http://kaczus.republika.pl
Mariusz Marszałkowski
> > błędy, w tym błędy w jego kodzie będą zawsze (a wtedy ma szanse je
> > dostrzec). Jesli temu zaprzecza, jego przydatność jest wątpliwa.
> > Stąd (moja subiektywna ocena) takie zjawisko, że statystyczny dobry
> > programista jest średnio bardziej pesymistycznym charakterem niż np.
> > statystyczny pracownik marketingu czy akwizycji.
>
> najgorszym z możliwych testerów własnego kodu. Bo automatycznie sprawdza
> przypadki, na które się zabezpieczył i głównie sprawdza, czy
> zabezpieczenia, które w kodzie wstawił zadziałają poprawnie.
Wszystko racja Panowie, tyle że w moim przypadku błędny fragment
kodu był testowany i działał poprawnie. W tym prostym przypadku nie
bardzo jest możliwa sytuacja kompensowania się błędów.
Przyjrzyjcie się uważnie, tu nie ma miejsca na kompensacje błędów:
1) Program testowany wykonuje obliczenia
2) Wynik obliczeń zapamiętuje w 6 znakowym stringu zakończonym zerem
3) Wyświetla stringa na standardowe wyjście po czym nie robi nic,
zawiesza
się tylko na standardowym wejściu
4) Program testujący odczytuje stringa, sprawdza czy wynik był
poprawny
5) Pominąwszy fakt czy wynik był poprawny czy nie, program testujący
odczytanego stringa przekazuje z powrotem do programu testowanego
6) Program testowany ma porównać odczytany string z zapamiętanym
wcześniej instrukcją if( strcmp( old_s , new_s ) ).
7) W instrukcji jest błąd, powinno być if( strcmp( old_s , new_s) ==
0 ) a
pomimo to około 1000 testów różnych wersji programu zadziałało
poprawnie.
Pozdrawiam
Jacek Czerwinski
> On 22 Gru, 11:49, Tomasz Kaczanowski
> <kaczus@dowyciecia_poczta.onet.pl> wrote:
>> Jacek Czerwinski pisze:
>>
>>> dostrzec). Jesli temu zaprzecza, jego przydatno�� jest w�tpliwa.
>> Zgadza si�. Dodatkowo - nale�y powiedzie�, �e programista jest
>> najgorszym z mo�liwych tester�w w�asnego kodu. Bo automatycznie sprawdza
>> przypadki, na kt�re si� zabezpieczy� i g��wnie sprawdza, czy
>> zabezpieczenia, kt�re w kodzie wstawi� zadzia�aj� poprawnie.
>
> Wszystko racja Panowie, tyle �e w moim przypadku b��dny fragment
> kodu by� testowany i dzia�a� poprawnie. W tym prostym przypadku nie
> bardzo jest mo�liwa sytuacja kompensowania si� b��d�w.
Kompensowanie b��d�w to tak p� �artem, p� serio.
Ca�kiem na serio, jest fesna�cie tysi�cy powod�w dla jakich b��d si� nie
ujawni.
>
> Przyjrzyjcie si� uwa�nie, tu nie ma miejsca na kompensacje b��d�w:
> 1) Program testowany wykonuje obliczenia
....
> pomimo to oko�o 1000 test�w r�nych wersji programu zadzia�a�o
> poprawnie.
testy nie s�u�a udowodnieniu, �e program jest bezb��dny. testu s�u��
znalezieniu b��d�w (tych kt�re si� dadz�). Test znalaz� b��d tzn �e ...
Test nie znalaz� b��du to co znaczy? Tzn �e nie znalaz�.
(Przypomnia� mi si� polityk kt�ry m�wi �e zabierze i �e da).
Niby produkcja z testami ma byc lepsza, i owszem jest. Tylko dlaczego w
zimie wi�cej jest w rowach aut z ABS, ASR, AXY, WC2 (wstawi� dowolny
skr�t). Usypianie uwagi.
Sebastian Kaliszewski
> Czasami patrzymy na kod programu, wszystko wydaje si� w porz�dku,
> czasami
> kod programu jest na tyle prosty, �e jeste�my pewni i� jest poprawny,
> mimo
> pewno�ci testujemy program i testy potwierdzaj� �e jest poprawny.
> Jednak tak
> kombinacji
> danych wej�ciowych, program nie zadzia�a, pomimo naszego
> do�wiadczenia,
> pomimo pewno�ci, pomimo prostoty kodu i nawet pomimo test�w tak
> naprawdďż˝
> kod zawiera b��d. To sytuacja kt�ra ka�demu programi�cie, bez wzgl�du
> na jego
> talent i do�wiadczenie, czasami si� przydarza.
>
> dostrzegamy (albo
> w ko�cu dostrzegamy) mo�e dzia�a� poprawnie? Do niedawna nigdy mi si�
> to nie
> przytrafi�o...
>
> wej�ciowe, przez
> programu w
> celu potwierdzenia poprawno�ci. Z powodu wymaga� protoko�u, ten inny
> program
> jeszcze raz z powrotem wysy�a� wyniki do mojego, a m�j jeszcze raz
> sprawdzaďż˝ czy
> doszed� do takich samych wynik�w.
>
> Mniej wi�cej wygl�da�o to tak, mamy dwa programy o nazwach A i B.
> A dostaje dane wej�ciowe
> B dostaje dane wej�ciowe
> B wykonuje obliczenia
> B weryfikuje czy wyniki sďż˝ identyczne
> B wysy�a do A
> A robi tylko(!) strcmp swojej kopii wynik�w
>
> B��d polega� na tym, �e zamiast if( strcmp(x,y) == 0 ) mia�em if
> ( strcmp(x,y) ).
> Ca�a heca polega na tym, �e to dzia�a�o! Przesz�o wiele test�w.
> Program
> by� rozbudowywany i po kilku rozbudowach ten fragment kodu ca�y czas
> dzia�a�
> test
> od razu na starcie si� wy�o�y�. Wy�o�y� si� w�a�nie na tym banalnym
> fragmencie z
> if( strcmp ) kt�ry od dawna dzia�a�, cho� nie mia� prawa dzia�a�.
Skompensowa�y si� 2 (lub wi�cej) b��dy(�w).
>
> �eby by�o ma�o, godzin� temu znalaz�em w programie analogiczn�
> sytuacjďż˝.
> Banalny b��d, zamiast "return true", wpisa�em "return false".
> Instrukcja w
> testach programu by�a wykonywana miliony razy i dzia�a�a poprawnie
> chociaďż˝
> nie mia�a prawa zadzia�a� ani razu.
A sk�d pewno�� �e kiedykolwiek zadzia�a�a? Robi�e� test pikrycia.
>
> Totalnie zg�upia�em. Zastanawia�em si� nad b��dem kompilatora, ale to
> nie
> jest prawdopodobne. Zastanawia�em si� czy to mo�e by� spowodowane
> specyficznymi
> instrukcjami niedost�pnymi na danym procesorze, ale w takich
> sytuacjach
> raczej ca�y program by si� rozsypa�. Mo�liwa jest tak�e sytuacja �e
> dwa
> b��dy wzajemnie si� znosi�y, ale co za b��d mo�e znosi� "return false"
> i
> zamieniaďż˝ na "return true"? Nie pojmujďż˝ tego.
Za du�o C, u�yj lepszego j�zyka ;)
A serio to...
1. Wcale nie by�a wykonywana (zdarza si�)
2. Jej wynik nie mia� znaczenia dla dzia�ania programu lub mia� nie we
wszystkich przypadkach, w ka�dym razie nie w takich jakie testowa�e� (np
to co ona liczy�a by�o maskowane przez inne obliczenia)
Mo�goby� cho�by "fused logical operators", czyli w przypadku:
if(co�tam && funkcja())
funkcja wykona si� tylko je�li co�tam by�o prawdziwe. M�g� te� by�
bardziej skomplikowany przypadek wy��czenia wykonania funkcji albo
w�a�nie zamaskowania jej wyniku.
\SK
--
"Never underestimate the power of human stupidity" -- L. Lang
--
http://www.tajga.org -- (some photos from my travels)
Marcin 'Qrczak' Kowalczyk
> int a=f();
>
> nie zwrocic wartosci (po prostu nie napisac return) a bb5
> wrzuci ci tam jakas wartosc i nawet nie zglosi zadnego bledu
To nie jest wina kompilatora - tak jest w C i C++.
Sebastian Kaliszewski
> On 22 Gru, 11:49, Tomasz Kaczanowski
> <kaczus@dowyciecia_poczta.onet.pl> wrote:
>> Jacek Czerwinski pisze:
>>
>>> dostrzec). Jesli temu zaprzecza, jego przydatno�� jest w�tpliwa.
>>> St�d (moja subiektywna ocena) takie zjawisko, �e statystyczny dobry
>>> statystyczny pracownik marketingu czy akwizycji.
>> przypadki, na kt�re si� zabezpieczy� i g��wnie sprawdza, czy
>
> Wszystko racja Panowie, tyle �e w moim przypadku b��dny fragment
> kodu by� testowany i dzia�a� poprawnie. W tym prostym przypadku nie
> bardzo jest mo�liwa sytuacja kompensowania si� b��d�w.
>
> 1) Program testowany wykonuje obliczenia
> 3) Wy�wietla stringa na standardowe wyj�cie po czym nie robi nic,
> zawiesza
> si� tylko na standardowym wej�ciu
> 4) Program testuj�cy odczytuje stringa, sprawdza czy wynik by�
> poprawny
> 5) Pomin�wszy fakt czy wynik by� poprawny czy nie, program testuj�cy
> odczytanego stringa przekazuje z powrotem do programu testowanego
> wcze�niej instrukcj� if( strcmp( old_s , new_s ) ).
> 7) W instrukcji jest b��d, powinno by� if( strcmp( old_s , new_s) ==
> 0 ) a
> pomimo to oko�o 1000 test�w r�nych wersji programu zadzia�a�o
> poprawnie.
B�ad masz jesze gdzie� pomi�dzy 4 a 7 a nawet dalej.
Zamiast si� upiera�, �e dziej� si� cuda lepiej poszukaj...
Jan Górski
> nie jest ujawniony. Literatura niezawodnościowa odróżnia błąd tkwiący
> sobie w programie (choćby 10 lat), a przypadek ujawnienia go.
>
> Kiedyś był eksperyment, zespół A testował program, ujawnił N błedów,
> zespół B ujawnił M błędów, w tym K powtarzających się z zespołem A. Na
> tej podstawie można się statystycznie doliczyć, że jest tam tyle a tyle
> nieznanych błędów. Było to bardzo dużo (K bardzo małe).
Tak się liczy liczbę zwierząt na danym terenie :-) Na podstawie
udziału % zwierząt oznakowanych w odłowieniu 1, podczas odłowienia 2.
Po drodze trzeba im jeszcze pozwolić się przemieszać. Ale to taki mały
offtop ;-)
Sebastian Nibisz
> Ale czy mo�e zdarzy� si� odwrotnie? Czy program z b��dami kt�re
> dostrzegamy (albo w ko�cu dostrzegamy) mo�e dzia�a� poprawnie?
Ja powiem wi�cej - s� sytuacje, gdzie pope�nianie b��d�w w kodzie bardzo sie
przydaje.
M�j konik to wymy�lanie algorytm�w stosowanych w przetwarzaniu obrazu. Po
opracowaniu teoretycznym algorytmu, przyst�puj� do jego implementacji. Na
tym etapie dzieje sie bardzo wiele ciekawych rzeczy. Poniewaďż˝ zdarza mi sie
pope�nia� b��dy implementacyjne, algorytm niejako przypadkowo, zostaje
poddany modyfikacjom. Te modyfikacje przynosz� r�ny efekt ale zdarza si�,
�e okazuj� sie bardzo korzystne. Pewnie nigdy by nie powsta�y, gdybym b��d�w
podczas implementacji nie pope�nia�.
Tak wi�c wszystko zale�y od tego co sie implementuje. Je�eli tylko
implementowany kod jest w pewnym sensie do�wiadczalny a za�o�ony wynik
dzia�ania programu nie jest precyzyjnie okre�lony, nie nale�y wystrzega� si�
pope�niania b��d�w.
Pozdrawiam,
- Bastek -
Mariusz Marszałkowski
> Mariusz Marszałkowski wrote:
> > Ale czy może zdarzyć się odwrotnie? Czy program z błędami które
> > dostrzegamy (albo w końcu dostrzegamy) może działać poprawnie?
>
> przydaje.
Zgadza się. Często mam ochotę "wymyślić" jakiś algorytm totalnie w
oderwaniu
od zastosowania. Myślę raczej o prostych algorytmach z jedną tablicą,
jedną
pętlą i kilkoma warunkami if. Wydaje się, że analizowanie takich
algorytmów
napisanych niemal na oślep jest bardziej pouczające niż pisanie pod
konkretne
zastosowanie.
Pozdrawiam
fir
szok w takim razie - to bezsensu
Mariusz Marszałkowski
> > On 22 Gru, 10:27, "fir" <profesor_kinb...@poczta.onet.pl> wrote:
>
> > > int a=f();
>
> > > nie zwrocic wartosci (po prostu nie napisac return) a bb5
> > > wrzuci ci tam jakas wartosc i nawet nie zglosi zadnego bledu
>
> > To nie jest wina kompilatora - tak jest w C i C++.
>
> szok w takim razie - to bezsensu
chcemy aby funkcja zwracała wartość, to piszemy void. Natomiast
w skomplikowanych kompilator i tak i tak nie wie czy wykona się
instrukcja "return coś".
Pozdrawiam
fir
> > > On 22 Gru, 10:27, "fir" <profesor_kinb...@poczta.onet.pl> wrote:
> >
>>> czasem kompilatory maja glupie dziury, o ile pamietam (a chyba tak)
>>> w borland builderze 5 np mozesz w funkcji
>>>
>>> np
>>>
>>> int f()
>>> {
>>> //...kode
>>>
>>> }
>>>
>>> int a=f();
>>>
>>> nie zwrocic wartosci (po prostu nie napisac return) a bb5
>>> wrzuci ci tam jakas wartosc i nawet nie zglosi zadnego bledu
>>>
>>> trudne do uwierzenia ale sam sie kiedys przekonalem ze tak jest
>>> gdy dzialy sie dziwne rzeczy
> >
> > > To nie jest wina kompilatora - tak jest w C i C++.
> >
> > szok w takim razie - to bezsensu
> W prostych funkcjach to bez sensu, gdy� je�li naprawd� nie
> chcemy aby funkcja zwraca�a warto��, to piszemy void. Natomiast
> w skomplikowanych kompilator i tak i tak nie wie czy wykona siďż˝
> instrukcja "return coďż˝".
1) chce aby f zwracala inta tylko chyba zapomnialem wtedy napisac return
(juz nie pamietam w kazdym razie po debugowaniu odkrylem niniejsza sytuacje)
2) jesli return nie ma nigdzie w ciele funkcji a funkcja ma zwracac
inta to ja nie uwazam ze nie zaraportowanie tego jako bledu jest
normalne
f
>
> Pozdrawiam
Wojciech "Spook" Sura
(...)
function test : integer; assembler;
asm
mov eax, 10;
end;
Jak my�lisz, jak� warto�� zwr�ci funkcja? ;]
Pozdrawiam -- Spook.
1664
> (...)
>
> function test : integer; assembler;
>
> asm
> end;
>
> Jak my�lisz, jak� warto�� zwr�ci funkcja? ;]
>
> Pozdrawiam -- Spook.
>
>
nie wiem... co to za jezyk, delphi? nie mam pojecia o delphi,
pewnie powinienem sie przyuczyc (jako ze ogolnie 'sympatyzuje
z borlandem'] :)
1664
Wojciech "Spook" Sura
news:095f.000001...@newsgate.onet.pl...
>> function test : integer; assembler;
>>
>> asm
>> end;
>>
>> Jak my�lisz, jak� warto�� zwr�ci funkcja? ;]
>
> pewnie powinienem sie przyuczyc (jako ze ogolnie 'sympatyzuje
> z borlandem'] :)
Spostrzeg�em si� poniewczasie, �e to nie pl.c.p, a pl.c.l.c, ale mam
nadziej�, �e m�j post zostanie mi wybaczony :)
Domy�lam si�, �e w C/C++ powy�sza konstrukcja jest r�wnie� mo�liwa, ale nie
znam tych j�zyk�w na tyle dobrze, �eby zaszpanowa� kodem.
Niemniej, idea jest chyba jasna :)
Pozdrawiam -- Spook.
--
! ._______. Warning: Lucida Console sig! //) !
! || spk || www.spook.freshsite.pl / _ """*!
! ||_____|| spook at op.pl / ' | ""!
! | ___ | tlen: spoko_ws gg:1290136 /. __/"\ '!
! |_|[]_|_| May the SOURCE be with you! \/) \ !
1664
> news:095f.000001...@newsgate.onet.pl...
> >> function test : integer; assembler;
> >>
> >> asm
> >> end;
> >>
> >> Jak my�lisz, jak� warto�� zwr�ci funkcja? ;]
> >
> > nie wiem... co to za jezyk, delphi? nie mam pojecia o delphi,
> > pewnie powinienem sie przyuczyc (jako ze ogolnie 'sympatyzuje
> > z borlandem'] :)
>
> Spostrzeg�em si� poniewczasie, �e to nie pl.c.p, a pl.c.l.c, ale mam
> nadziej�, �e m�j post zostanie mi wybaczony :)
>
nie przejmuj sie, czuj duch - mz i tak jest za malo dygresji na tej
grupie, gdyby wrzucac jakies ciekawe to byloby ciekawiej
> Domy�lam si�, �e w C/C++ powy�sza konstrukcja jest r�wnie� mo�liwa, ale nie
> znam tych j�zyk�w na tyle dobrze, �eby zaszpanowa� kodem.
>
> Niemniej, idea jest chyba jasna :)
no tak ale 1) i tak da sie to zdetektowac 2) jak kompilator
nie chce sie meczyc (strasznie leniwy doprawdy musialby byc)
to moze sobie zawezic przypadki do raportowanie bledu do przypadkow
gdy nie ma ni returna ani takiego asma inline
kiedys rozmawialem z jednym kumplem w temacie tego ze kompilatory
robia za malo rzeczy na kodzie (a mozna by duzo, statystyki, rozne
grafy itp) i ten kumpel powiedzial 'no tak, ale chodzi o to ze
kompilator powinien byc przede wszystkim szybki' bardzo sluszna
uwaga - ale moga byc przecies dwa albo trzy tryby kompilacji
1664
> Pozdrawiam -- Spook.
>
> --
> ! ._______. Warning: Lucida Console sig! ďż˝ ďż˝//) ďż˝ ďż˝!
> ! || spk || � �www.spook.freshsite.pl � � �/ _ """*!
> ! ||_____|| � � � �spook at op.pl � � � � / ' �| ""!
> ! | �___ �| � tlen: spoko_ws gg:1290136 �/. __/"\ '!
> ! |_|[]_|_| �May the SOURCE be with you! \/) � � \ !