w wiki jest napisane:

"Two schemes are most common. The first, dynamic registration, generates code
that continually updates structures about the program state in terms of
exception handling.[8] Typically, this adds a new element to the stack frame
layout that knows what handlers are available for the function or method
associated with that frame; if an exception is thrown, a pointer in the
layout directs the runtime to the appropriate handler code. This approach is
compact in terms of space, but adds execution overhead on frame entry and
exit. It was commonly used in many Ada implementations, for example, where
complex generation and runtime support was already needed for many other
language features. Dynamic registration, being fairly straightforward to
define, is amenable to proof of correctness.[9]

The second scheme, and the one implemented in many production-quality C++
compilers, is a table-driven approach. This creates static tables at compile
and link time that relate ranges of the program counter to the program state
with respect to exception handling.[10] Then, if an exception is thrown, the
runtime system looks up the current instruction location in the tables and
determines what handlers are in play and what needs to be done. This approach
minimizes executive overhead for the case where an exception is not thrown,
albeit at the cost of some space, although said space can be allocated into
read-only, special-purpose data sections that are not loaded or relocated
until and unless an exception is thrown.[11] This second approach is also
superior in terms of achieving thread safety."

czyli gdyby to drugie u mnie dzialalo to bym mial spowolnienia w
loader time i nawet nie wiem,

jak wspomnialem mz wykorzystanie wyjatkow by wylaczyc na stale jakas
funkcje/galaz z ktorej polecial jakis niezidentyfikowany blad moze
byc moze miec ew pewien sens - (poki co jedyne ew sensowne dzialanie
jakiemi sie z tym kojarzy) - ale nie pisze poki co programow
ktore by tego wymagaly a wolalbym kiedys przemyslec obsluge bledow w
szerszy i ogolnijszy sposob

co do longjmp to ta struktura pod b55 jest np taka

typedef struct __jmp_buf {
unsigned j_ebp;
unsigned j_ebx;
unsigned j_edi;
unsigned j_esi;
unsigned j_esp;
unsigned j_ret;
unsigned j_excep;
unsigned j_context;
} jmp_buf[1];

nie wiem po co niektore pola (np edi esi ebx, czy to potrzeba zachowania
czesci kontekstu funkcji z catch? ani co to jest j_ret) bo srednio sie
w tym orientuje - ogolnie wydaje sie to byc jednak kwestia obslugi
mechanizmu powrotu w tyl po drzewku a nie samych kwestii z wyjatkami
(bo same powroty mozna rozpatrywac w oderwaniu od wyjatkow)







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

do góry

>
> Gdzie tu jest problem z wydajnością, albo z ogromną pamięcią? Nie
> mogę się doszukać. Lippman bzdury pisał czy ja czegoś nie rozumiem?
>

o ile chodzi o sam "long ret" (raczej nie powinno sie to nazywac
long jump) czyli np ret pod label

void fu()
{
ret somewhera_back;
}

to mz nie powinno to byc chyba wolniejsze niz zwykly ret,
trzeba zaladowac odwinieta wartosc wskaznika stosu (jest znana
statycznie) i skoczyc pod label

mov esp, 0x45526536
jmp somewhere_back

chyba tylko tyle - i moze wlasnie ew takie rety pod label
sporadycznie przydalyby sie w jezyku


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

do góry

Złapanie GPFa pod windą jest możliwe dzięki structured exceptions.

A swoją drogą, jeśli nie robisz tego celowo, zacznij korzystać z przeglądarki
sprawdzającej pisownię, bo to aż w oczy kłuje :/

do góry

<f...@g...skasuj-to.pl> wrote:

> jak wspomnialem mz wykorzystanie wyjatkow by wylaczyc na stale jakas
> funkcje/galaz z ktorej polecial jakis niezidentyfikowany blad moze
> byc moze miec ew pewien sens - (poki co jedyne ew sensowne dzialanie
> jakiemi sie z tym kojarzy) - ale nie pisze poki co programow
> ktore by tego wymagaly a wolalbym kiedys przemyslec obsluge bledow w
> szerszy i ogolnijszy sposob

Ukrywanie błędów to ślepa uliczka. Tak długo, jak nie masz pewności, co
właściwie się stało, próba kontrolowanego kontynuowania programu może
być ryzykowna. Chociażby dlatego że nie wiesz w jakim stanie jest heap,
w końcu poszedł wyjątek = coś poszło nie tak jak przewidziano.

M.in. dlatego stosowanie catchall jest przez wielu uznawane za złą praktykę.

Osobna sprawa to catch własnego wyjątku - ja często w miejscach, w których
zakładam, że coś powinno być tak a nie inaczej, daję dla pewności coś ala
assert - ale własny, zawsze kompilowany, a nie biblioteczny (który rozwijany
jest tylko w wersji debugowej). Makro sprawdza warunek i jak jest niezgodny,
to rzuca wyjątek z określoną treścią, np:

int rs = funkcja();
Assert(rs == 3, "%d", rs);

switch (a)
{
case ...:
break;
default:
Assert(false, "%d", a);
}

Wtedy funkcja łapiąca wyjątek może wypisać komunikat i wyjść, a main wtedy
zakończy program (dbam o to żeby miejsce wyjścia z programu było tylko
jedno).

> nie wiem po co niektore pola (np edi esi ebx, czy to potrzeba zachowania
> czesci kontekstu funkcji z catch? ani co to jest j_ret)

Jak chcesz programować wysokopoziomowo to musisz nauczyć się myśleć
wysokopoziomowo. Rejestry zostaw kompilatorowi.

--
Gof

do góry

g...@n...invalid (Adam Wysocki) napisał(a):

> Ukrywanie błędów to ślepa uliczka.
[...]
> zakończy program (dbam o to żeby miejsce wyjścia z programu było tylko
> jedno).

Nie ma innego wyjścia, kod diagnostyczny w każdym większym programie
musi stanowić jego istotną część. Kilka lat temu z wersji release
przestałem usuwać kod diagnostyczny. Gdy ważna jest wydajność, albo
gdy asercja jest bardzo czasochłonna, to można stosować testy na
wyrywki, typu:

if( rand() % 1024 == 0 )
test(...);

Pozdrawiam






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

do góry

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 */

do góry

> Jak chcesz programować wysokopoziomowo to musisz nauczyć się myśleć
> wysokopoziomowo.

hehe, nie mam takiego zamiaru



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

do góry