On 03/28/2012 08:51 AM, M.M. wrote:
> Czesc
>
> Kiedyś dawno z lat temu 10 albo jeszcze dawniej, przeczytałem
> straszną rzecz o wyjątkach w C++. Pisał sam Lippman więc się trochę
> przejąłem. Pisał on mianowicie że po włączeniu wyjątków skompilowany
> program nie zmieścił się w pamięci ram. Nie zastanawiając się głębiej
> uznałem że wyjątki wiążą się z jakimś narzutem i gdy była ważna
> szybkość działania programu to ich nie używałem.
>
> Teraz gdy się zastanawiam to wydaje mi się kompletnie bezsensowne aby
> wyjątki wiązały się z jakimś dużym narzutem. Do czego ten narzut niby jest
> potrzebny?
>
> Gdy kompilator napotyka instrukcję try to co musi zrobić? Moim zdaniem
> musi gdzieś zapamiętać adres wejścia do sekcji catch. Coś takiego
> chyba najlepiej zapamiętać na jakimś stosie. Więc dużo zależy od tego
> jak stos jest realizowany. Jeśli odkładanie elementu na stos jest
> związane z malloc to mamy narzut taki sam jaki narzut ma malloc. Jeśli
> stos jest budowany bez malloc to narzut jest pomijalny, wystarczy tylko
> zapamiętać trochę danych, może z 20-30 bajtów.
>
> Gdy kompilator napotyka koniec sekcji catch to co musi zrobić? Chyba tylko
> musi usunąć ze stosu to co wcześniej na nim zapamiętał. Więc o wydajności
> decyduje sposób w jaki to kompilator zapamiętuje.
>
> A co gdy kompilator napotyka throw Object? Zdaje się że musi odczytać
> kolejno zapamiętane informacje przy napotkaniu try. Jeśli znajdzie
> pasujący catch( Object ) to musi odtworzyć stos pointer. Potem na stos
> odkłada Object i musi zrobić long jump do odpowiedniego catch.
>
> Jednak wyjatki rzadko sie uaktywniają. Najczęściej mamy
> if( false ) throw Object. Czy kompilator jak widzi ze w
> procedurze jest throw Object to musi wygenerować jakiś
> kod który się wykona pomimo że wyjątek nie będzie rzucony?
> Moim zdaniem nie musi.
>
> Gdzie tu jest problem z wydajnością, albo z ogromną pamięcią? Nie
> mogę się doszukać. Lippman bzdury pisał czy ja czegoś nie rozumiem?
>
> Pozdrawiam


hejka,

zapewne mowa o dość starej książce Lippmana. :) tak w b. dużym skrócie
sprawa ma się tak: stare podejście "dynamiczne" powodowało odkładanie na
stosie sporo śmiecia, by program wiedział jakie obiekty niszczyć w
przypadku zgłoszenia wyjątku. oznacza to wzrost rozmiaru binarki i sporo
dodatkowej pamięci na stosie. było tak na początku lat '90. obecnie
stosuje się podejście "tablicowe" (pomysł z połowy lat '90), które nie
powoduje ŻADNEGO narzutu czasowego ani pamięciowego, podczas normalnego
(i.e. nie-wyjątkowego) przebiegu. w praktyce oznacza to, że jest
"tańsze" niż ręczne klepanie kodów powrotu, które zawsze trzeba
sprawdzić. :) użycie wyjątków powoduje jedynie zwiększenie binarki o
~10-20%, na wygenerowanie w/w tablic.

niedawno pisałem o tym na blogu:
http://www.baszerr.eu/doku.php/blog/2012/02/26/1
są też przykładowe kody do pobrania i odpalenia - można się pobawić.

dla osób zainteresowanych problematyką narzutów C++ polecam doskonały
raport techniczny:
http://www.open-std.org/jtc1/sc22/wg21/docs/TR18015.
pdf
obalonych jest tam mnóstwo mitów, również ten o narzucie jakie powodują
wyjątki (podrozdział 5.4).

świat się zmienia, technologia idzie do przodu a wiedza się
dezaktualizuje... :)

--
pozdrawiam serdecznie / best regards,
bartek szurgot
/* http://www.baszerr.eu */