Kiedyś moja żona wynalazła gdzieś stwierdzenie, że "ekspert to osoba która popełniła wszystkie możliwe błędy w swojej działce"* - i chyba coś w tym jest. Zauważmy, że programista na poziomie eksperckim/zaawansowanym rzadko kiedy dopytuje się "co zrobić gdy wyskoczył mi taki a taki błąd (np. kompilatora)" - on już te błędy widział, on już je kiedyś popełnił i nauczył się je rozwiązywać. Natomiast pytania od początkujących (a czasem i średnio-zaawansowanych) programistów dotyczą często właśnie tego "co zrobić gdy kompilator rzucił takim a takim błędem". Łącząc cytat z pytaniem, chciałbym zaproponować pewne ćwiczenie :)
Ćwiczenie: Zrób jak najwięcej różnych błędów.
A konkretniej, chodzi o to by stworzyć serię mini-programików/skrypcików i w każdym zrobić inny błąd, tj. żeby kompilator/linker/preprocesor/interpreter/etc podczas kompilacji/interpretacji/etc wyrzucał inny kod błędu czy też inny komunikat. Jeden programik - jeden błąd.
Ćwiczenie jest proste jeśli chodzi o zasadę działania, ale wraz z jego wykonywaniem, robi się coraz trudniejsze - ciekawe po ilu różnych błędach Tobie skończą się pomysły na następny :)
Domyślam się, że w pewnym momencie będzie trzeba skorzystać z dokumentacji kompilatora/etc, w której po prostu jest lista wykrywanych przez kompilator błędów, wraz z ich opisem, a czasem nawet przykładem (co znacznie ułatwi sprawę) - gorąco zachęcam do nauczenia się korzystania z tej sekcji dokumentacji!
Tak więc zachęcam, szczególnie początkujących programistów, do wykonania powyższego ćwiczenia, a także do podzielenia się spostrzeżeniami :)
* osobiście preferuję definicję "ekspert - osoba spoza miasta pokazująca slajdy" ;>
2010-04-23:
Comments:
M.in o ten spis mi chodziło (jest na prawdę niezły ;>) :)
Natomiast zachęcam najpierw do spróbowania bez spisu, a dopiero jak się pomysły skończą, to posłużenie się listą błędów :)
Po tym jak pół dnia debugowałem kiedyś plik wsadowy, który miał mi przyspieszyć pracę nad programem, tudzież po pół dnia debugowania, czemu jeden obrazek się nie wyświetla na monitorze (monitor był monochromatyczny, a obrazek zrobiony z kolorów o identycznej jasności…), dałem sobie siana. };>
Akcja z monitorem - Ahahahahaha kapitalne ;))))
(dlatego uwielbiam prelekcje/wypowiedzi ludzi którzy mają doświadczenie w branży - dla takich anegdot ;>)
Pliki wsadowe są z natury złośliwym tworem - wiem coś o tym ;)
Ostatnio wpadłem na taki pomysł aby zdefiniować sobie takie makro:
#define private public
Chciałem zobaczyć czy to przejdzie :P Co się okazało: ani g++ ani vc++ nic nie wykrzaczył. To chyba tylko jako ciekawostka ;p
"C:
You shoot yourself in the foot.
C++:
You accidently create a dozen instances of yourself and shoot them all in the foot. Providing emergency medical care is impossible since you can't tell which are bitwise copies and which are just pointing at others and saying, "that's me, over there.""
http://burks.bton.ac.uk/burks/language/shoot.htm
Pozdrawiam
P.S. Albo Captcha szwankuje albo nie potrafię rozwiązać 2*10+9
Któreś z kolei prawo Murphy'ego. Smutne lecz prawdziwe.
zacznij uzywac jezykow mocno typizowanych, najlepiej deklaratywnych, przeszedl typechecker znaczy ze dziala (modulo bledy logiczne)
Niby zawsze wiem, że nie ma "new", ale bardzo często ten błąd mnie zatrzymuje na dłużej.
Co do makra, to się nie dziwie ;) Nie ma powodu dla którego to by miało nie działać ;)
Ano, google zazwyczaj wystarcza, ale nie zawsze niestety...
@Tomasz Kowalczyk
;DDD LOL ;)
@Rradom
Truee ;))
Co do captcha... to muszę zmienić trochę zasadę działania, bo czasem zachodzi race condition i nie przyjmuje poprawnego wyniku ;D
@Mateusz Krzywicki
Ba! Jest dokładnie tak jak napisałeś :)
Hehe jak coś skrobiemy ze znajomymi, to co jakiś czas (po jakimś 0.5-2h klepania bez kompilacji) leci "kurde, skompilowało się bez błędów :("... a potem debugowanie... yh ;D
@mak
Nawet w C czy C++ które są mocno typizowane takie rzeczy się zdarzają ;)
@Karton
;D :)))
Mi kiedyś 2 tyg zeszło na błąd typu sizeof(struktura*) zamiast sizeof(struktura) ;DDD
A nie ?;> Na /W4 ? ;>
Hmm, a eng wiki jest tabelka z porównaniami typizowania:
http://en.wikipedia.org/wiki/Comparison_of_programming_languages
C++ jest jako strong, natomiast C jest jako weak.
W przypadku kompilacji z /W4 (VC++) czy analogicznej w innych kompilatorach, kontrola typów jest jeszcze silniejsza, również w przypadku C.
int i;
for (i = 0; i < num_items; i++);
{
items[i] = ItemFactory::createItem(/* jakieś parametry */);
}
Kilka minut na to patrzylem i nie moglem znalezc bledu... myslalem, ze chodzi o jakies zaawansowane operacje, juz rozmyslalem nad skutkami przeladowania roznych operatorow i w ogole czego to ja nie wymyslilem... A chodzilo o zwykly srednik - ten po for (int i=0; i<num_items; i++); :) Ktos sie troche rozpedzil podczas pisanie kodu i z przyzwyczajenia na koncu linii dal srednik. Link do tematu dla zainteresowanych:
http://forum.4programmers.net/viewtopic.php?id=141606&start=225
Taak, to jest dobry motyw ;)
Kiedyś na teście kompetencyjnym z C takie coś widziałem, a i ze 2 razy w życiu taki błąd również udało mi się zrobić ;)))
Wyżej dałem linka do wiki, który twierdzi że C++ jest silnie typizowany. Jeśli uważasz, że nie mają racji, to może weź tam popraw ? :)
@mak: Aha, czyli Haskell nie ma silnej typizacji (są takie cholerstwa jak unsafeCoerce)?
unsafeCoerce to brzydki hak zbudowany na wierzchu rodziny unsafe*IO ktory sprawia ze system typow jest nie spojny, mowiac o haskellowym systemie take rzeczy sie przemilcza ;]
Zauwaz ze obie funkcje sa wbudowane w kompilator
i nie da sie ich wyrazic w jezyku jako takim
fajnie wiedziec ze w takim miejscu mozna spotkac ludzi ktorzy wiedza co to haskell (w takim, w sensie nie zwiaznaym z teoria jezykow i pochodnymi )
Stąd moja sugestia aby poprawić ;> To była propozycja na serio :)
@mak
Ehehe spoko, zdaję sobie sprawę, że z teorią języków mam tyle wspólnego co z językiem polskim ;)))
Add a comment: