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


--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

On Wednesday, March 28, 2012 7:51:52 AM UTC+1, 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.

Kompilatory C++ sprzed 10 lat sa tak rozne od dzisiejszych, ze opieranie sie na
materialach sprzed dekady na temat wydajnosci C++ jest bez sensu, niezaleznie od tego
kto pisal dany artykul.

RW

do góry

M.M. <m...@g...pl> napisał(a):

> 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
>
>
a ja od dawna sie zastanawiam jak upewnic sie (na 100%) ze kompilator
nie wstawia mi jakiegos spowolnienia zwiazanego z obsluga wyjatkow
(ktorych nie uzywam), czy zajrzenie do zrodla w asmie i nie
dostrzezenie tam nic dziwnego (bez co prawda wglebiania sie
w dokladnie czytanie) to gwarancja, ze nie mam zadnych wiazacych sie
z tym spowolnien? (pewnie tak bo jakies grzebanie w prologach i epilogach
to bym pewnie zauwazyl)







--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

<f...@g...pl> napisał(a):

> M.M. <m...@g...pl> napisał(a):
>
> > 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
> >
> >
> a ja od dawna sie zastanawiam jak upewnic sie (na 100%) ze kompilator
> nie wstawia mi jakiegos spowolnienia zwiazanego z obsluga wyjatkow
> (ktorych nie uzywam), czy zajrzenie do zrodla w asmie i nie
> dostrzezenie tam nic dziwnego (bez co prawda wglebiania sie
> w dokladnie czytanie) to gwarancja, ze nie mam zadnych wiazacych sie
> z tym spowolnien? (pewnie tak bo jakies grzebanie w prologach i epilogach
> to bym pewnie zauwazyl)

Można napisać jakiś program i zmierzyć czasy wykonania. Jeśli nikt nie
odpowie to tak zrobię :)
Pozdrawiam



--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

On 28 Mar, 08:51, "M.M." <m...@g...pl> wrote:
> Gdzie tu jest problem z wydajnością, albo z ogromną pamięcią? Nie
> mogę się doszukać. Lippman bzdury pisał czy ja czegoś nie rozumiem?

Obecnie kompilatory używają tzw. zero-cost model. Hasło do googla: "c+
+ exception zero-cost"

Pozdrawiam
KK

do góry

Dnia Wed, 28 Mar 2012 06:51:52 +0000, M.M. napisal:

> 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.

Dzisiaj różnica w szybkości działania jest prawie żadna, o ile
wyjątek nie jest rzucony. Jest narzut na obsługę wyjątku w postaci
kodu obsługującego (czy masło jest wystarczająco maślane? ;) i
straconych optymalizacji - to już zależy od języka i implementacji
wyjątków.

Odniosę się do C++ głównie.

> 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?

Musi być kod robiący wszystko to, co jest przewidziane. W C++ oznacza
to destrukcję lokalnych obiektów, sprawdzenie catch-clauses i
unexpected-handlera, poza samym stack unwind.

>
> 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.

Implementacja zależy od języka. W c++ zapamiętuje się call-site'y
i opisuje zachowanie na wypadek wyjątku w specjalnych strukturach.

W Javie (bytekod) zapamiętuje się regiony.

>
> 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.

(?) Nie kompiluje mi się to co napisałeś.

>
> 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.

Sam fakt, że wyjątek ma stos zmienia optymalizacje. W c++
stos zależy od optymalizacji; w Javie generalnie nie, ale czasami
tak.

>
> 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?

Przykład z Javy: jeżeli JIT ciężko optymalizuje fragment kodu,
odwołuje się do referencji. Domyślnie mimo wszystko zakłada, że mogą
być null-em, ale upraszcza rzucanie NullPE - rzucane są bez stosu
w ogóle, nie tylko stosu bez wyoptymalizowanego fragmentu. Jest opcja,
która zmienia zachowanie i NPE zawsze ma stos, kosztem słabszej
optymalizacji.

Sam fakt, że JIT domyślnie upraszcza zachowanie tak, że zmienia
semantykę NPE, świadczy o tym, że architekci uznali że warto.

Edek

do góry

Edek Pienkowski <e...@g...com> napisał(a):

> Dzisiaj różnica w szybkości działania jest prawie żadna, o ile
> wyjątek nie jest rzucony. Jest narzut na obsługę wyjątku w postaci
> kodu obsługującego (czy masło jest wystarczająco maślane? ;) i
> straconych optymalizacji - to już zależy od języka i implementacji
> wyjątków.
Dziękuję z utwierdzenie mnie w tym przekonaniu :)

> Musi być kod robiący wszystko to, co jest przewidziane. W C++ oznacza
> to destrukcję lokalnych obiektów, sprawdzenie catch-clauses i
> unexpected-handlera, poza samym stack unwind.
No tak, ale to wszystko musi także wykonać bez wyjątków w
momencie gdy napotyka return? Hmmm a tak na marginesie gdy napotyka
longjump to co robi? Też robi destrukcje obiektów na stosie?


> > 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.


> (?) Nie kompiluje mi się to co napisałeś.
Nie wiem dokładnie jak nowoczesne kompilator/optymalizatory realizują obsługę
wyjątków. Wyobrażam sobie to jako jakąś strukturę stosową. Gdy
wykonanie programu dochodzi do sekcji try to na tą strukturę odkładana
jest jakaś informacja. Więc gdy wykonanie programu dojdzie do końca
sekcji catch to coś z tej struktury stosowej musi zdjąć. Jest to
związane z jakimś narzutem. Nie wiem na pewno, ale wydaje się że ów
narzut jest bardzo mały.

> Sam fakt, że wyjątek ma stos zmienia optymalizacje. W c++
> stos zależy od optymalizacji; w Javie generalnie nie, ale czasami
> tak.
Hmmmm zapewne tak. Ale czy to nie jest podobne utrudnienie optymalizacji
dla kompilatora jak po dodaniu instrukcji if? Kompilator generuje gorszy
kod gdy są wyjątki?

> Sam fakt, że JIT domyślnie upraszcza zachowanie tak, że zmienia
> semantykę NPE, świadczy o tym, że architekci uznali że warto.
Hmmm to chyba jednak zrobię kiedyś przy okazji jakiś mały benchmark :)

Pozdrawiam


--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

Dnia Wed, 28 Mar 2012 13:32:27 +0000, M.M. napisal:

> Edek Pienkowski <e...@g...com> napisał(a):

>
>> Musi być kod robiący wszystko to, co jest przewidziane. W C++ oznacza
>> to destrukcję lokalnych obiektów, sprawdzenie catch-clauses i
>> unexpected-handlera, poza samym stack unwind.
> No tak, ale to wszystko musi także wykonać bez wyjątków w
> momencie gdy napotyka return?

No nie w tym samym miejscu, mniej optymalizowalne, w skrócie
trochę się to różni:

OnStack s1();

call_meth();

OnStack s2();
...

Jeżeli call rzuci, to musi tylko s1 skasować.

Jeżeli nie używa się wyjątków, kompilowanie z wyjątkami
generuje kod "skasuj tylko s1". Czy jakoś tak, chodzi mi
raczej o ogólną zasadę niż konkretnie o ten przykład.

> Hmmm a tak na marginesie gdy napotyka
> longjump to co robi? Też robi destrukcje obiektów na stosie?

Na mojej mapie longjmp jest tam gdzie mieszkają smoki.

>
>
>> > 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.
>
>
>> (?) Nie kompiluje mi się to co napisałeś.
> Nie wiem dokładnie jak nowoczesne kompilator/optymalizatory realizują obsługę
> wyjątków. Wyobrażam sobie to jako jakąś strukturę stosową. Gdy
> wykonanie programu dochodzi do sekcji try to na tą strukturę odkładana
> jest jakaś informacja. Więc gdy wykonanie programu dojdzie do końca
> sekcji catch to coś z tej struktury stosowej musi zdjąć. Jest to
> związane z jakimś narzutem. Nie wiem na pewno, ale wydaje się że ów
> narzut jest bardzo mały.

Te implementacje które znam działają inaczej. Stos jest właściwie
taki sam jak bez wyjątków; wyjątki robią procedurę zwijania stosu
aż znajdą odpowiedni handler.

Polecam wikipedię, sam poczytam o innych implementacjach, bo wiem
że istnieją inne.

>
>> Sam fakt, że wyjątek ma stos zmienia optymalizacje. W c++
>> stos zależy od optymalizacji; w Javie generalnie nie, ale czasami
>> tak.
> Hmmmm zapewne tak. Ale czy to nie jest podobne utrudnienie optymalizacji
> dla kompilatora jak po dodaniu instrukcji if? Kompilator generuje gorszy
> kod gdy są wyjątki?

Jeżeli w kodzie nie ma wyjątków a kompiluje się z wyjątkami, jest
trosecke niepotrzebnego kodu. Ten kod nie powinien za bardzo
spowalniać, powinien być traktowany jako slow-path.

W sumie ciekawe pytanie, nie wiem, ale cokolwiek się napisze
ma wpływ na optymalizacje (poza abstraction penalty, które już
od dość dawna prawie nie istnieje).

Edek

do góry

M.M. <m...@g...pl> napisał(a):

> <f...@g...pl> napisał(a):
>
> > M.M. <m...@g...pl> napisał(a):
> >
> > > 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
> > >
> > >
> > a ja od dawna sie zastanawiam jak upewnic sie (na 100%) ze kompilator
> > nie wstawia mi jakiegos spowolnienia zwiazanego z obsluga wyjatkow
> > (ktorych nie uzywam), czy zajrzenie do zrodla w asmie i nie
> > dostrzezenie tam nic dziwnego (bez co prawda wglebiania sie
> > w dokladnie czytanie) to gwarancja, ze nie mam zadnych wiazacych sie
> > z tym spowolnien? (pewnie tak bo jakies grzebanie w prologach i epilogach
> > to bym pewnie zauwazyl)
>
> Można napisać jakiś program i zmierzyć czasy wykonania. Jeśli nikt nie
> odpowie to tak zrobię :)
> Pozdrawiam
>
>
trzeba przeczytac w necie jest raczej duzo info - sam moge odpowiedziec
jak przeczytam (tyle ze troche pozniej bo wlasnie wrocilem z malej
wloczego balangi (ostatnio trace duzo czasu) i jestem b zmeczony)


--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

ogolnie ostatnio milalem chyba jakies przemyslenie zachaczajace
o wyjatki ale zapomnialem

poki co rozumiem czesciowo ten koncept,

nie wiem naprzyklad czy catchami mozna lapac systemowe wyjatki
typu gpf 0=2; wykonanie nieprawidlowej instrokcji, czy div by zero 1/0; ?
(i o ile tak to czy mozna to lapac w jakis inny sposob?)

ogolnie przychodzi mi do glowy chyba tylko taki sposob uzycia
tego ze decydojemy sie ze jakis/jakikolwiek blad w obrebie jakiejs
podgalezi kodu ma spowodowac skok do jej podnuza (lokalne zmienne
sa zwijane a globalne encje sostawiane tak jak w momencie bledu)
po czym u tego 'podnuza' ustawiamy flage bitową ktora w dalszym
toku dzialania progsa powowduje ze ta podgalaz bedzie po peostu
niewywolywana - taki sposob ratunku calego programu przez
odlaczanie galezi w ktorej gdzies wystapil jakis blad

ew jakies inne zastosowania?

- sam jednak poki co nie zajmuje sie pisaniem takich
programow ktore mialyby byc w taki sposob podtrzymywane
przy zyciu w wypadku bledu tak ze zwykle ERROR("costam")
i exit to dla mnie prostsza sprawa




--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry