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/