From: Kamal R. Prasad [EMAIL PROTECTED]
Im sorry I didn't understand you. setjmp() stores a few register contents
[notably ip] in a jmpbuf -which are restored after a longjmp(). How is the
try/catch mechanism more efficient than a setjmp()/longjmp() in terms of
space/time complexity?
try/catch stores less. Besides, longjmp() is nothing like
try/catch. The whole point of try/catch is that as the
stack gets unwound, all the auto-class objects get
properly destroyed. When you do longjmp, you just move
the instruction pointer and stack pointer, and if
any of the objects on the stack contained pointers
to any dynamically allocated memory, it gets lost.
If there were any file descriptors opened along the way,
they are left open too. If there were any locks held,
they stay locked. To prevent this loss with longjmp, you
have to track all these objects manually.
Note that even with try/catch it's a Real Bad Idea to throw
exceptions from constructors and destructors, as this
causes complications.
-SB
On 7/12/06, Joerg Sonnenberger [EMAIL PROTECTED] wrote:
On Wed, Jul 12, 2006 at 06:33:09PM +0530, Kamal R. Prasad wrote:
On 7/12/06, Joerg Sonnenberger [EMAIL PROTECTED] wrote:
On Tue, Jul 11, 2006 at 11:37:52PM +0200, Attilio Rao wrote:
Even if I have no proof-of-concepts (so maybe somebody can show that
this is not fair), if we have setjmp/longjmp in the kernel we can
have
a correct exception handling mechanism without not great problems.
ROFL. Sorry, but using setjmp/longjmp is one of the worst possible
implementation of exceptions since it is very expensive for the hot
path, where you don't expect exceptions. They are called exception
for
a reason.
so how is exception handling in C++ more efficient than
setjmp()/longjmp()
-in either paths?
The common implementations are based on two assumptions:
- try {} is used often through out the tree and nested
- exceptions are raised seldomly.
This means that the desire to catch an exception should be cheap and the
implementation optimised for that.
What happens is that the compiler creates a table which allows automatic
stack unwinding and matching of the instruction pointers. The former is
necessary to handle frame pointer vs. frame pointer-less stack frames,
the latter is used to determine where an exception should be cought.
Consider:
void bar()
{
throw foo;
}
void foo()
{
try {
bar();
} catch(...) {
cerr error;
}
}
(don't try that, I haven't written C++ for ages)
The compiler creates:
- an entry for the range of bar to annotate that it doesn't have use a
frame pointer
- an entry for foo, with the same annotation
- the address when bar is called in foo (or the address directly
following) to annotate that it should jump to catch, when an exception
is raised.
When an exception is raised, it looks at the current instruction pointer
and begins unwinding the stack until a catch is found. This can be
relatively cheap compared to longjmp, since the register content does
not have to be restored. It does not add any slowdown, as long as
exceptions are not raised.
Joerg
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
