DaWei

To me, one of the benefits of being old and cranky is that I know there are tons of compilers that are old and cranky, haven't read the standards, and don't kowtow to the high priests even when they oughtta. The other is that I can conveniently not "remember" who wrote that crappy looking code.

__________________
Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code.
Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

grumpy

Don't forget the ... joy ... of wondering "what idiot wrote this?", and then looking at the maintenance log and having your memory refreshed.

mitakeet

Another reason for using return codes vs exceptions for routine error handling is performance. I believe I read in one of Bjarne's books that exception handling is deliberately not required to be efficient in any of the standards because exceptions are expected to be exceptional and NOT routine. Stack unwinding typically completely destroys locality and temporality of code, results in massive cache misses and often leading to cache thrashing. Thus, where a simple return code might result in 20-100 cycles to process (depending on circumstances), an exception could easily take 10,000 or more cycles (when you add in the cumulative effect of the cache misses). Now imagine this is in some inner loop in a compute bound part of your program, how would you code it?

__________________

Free code: http://sol-biotech.com/code/.

It is not that old programmers are any smarter or code better, it is just that they have made the same stupid mistake so many times that it is second nature to fix it.
--Mitakeet

The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man.
--George Bernard Shaw

grumpy

While it is true that the C++ standard does not specifically require efficient exception handling, market forces (i.e. vocal programmers) have tended to drive compiler writers in that direction. About 10 years ago, the exception handling provided with most compilers was, to put it gently, not terribly efficient.

The way a C++ program is required to behave, when returning from a function (or even exiting from a code block), is that all local (auto) objects will be destroyed (i.e. for local class objects with destructors, the destructors will be invoked). The overhead of that is potentially considerable, but is required to avoid nasty things like memory leakage. The same is required when an exception is thrown.

The other overheads specifically associated with exceptions are related to;
1) maintaining information about the exception thrown. A simple minded implementation of stack unwinding will copy the exception repetitively up the call stack until it is caught. More modern implementations will copy the exception to some defined place, and simply check if an exception is active rather than copying it many times.
2) the need for a function to return immediately (after doing required cleanup) can mean that code is needed around every potential operation (i.e. a function call) that might yield an exception. This can have run time impacts, but is sort of equivalent to having to check error codes at every step.
3) the implementation of exception catching requires examination of the type of object thrown and comparison with the type being caught by the catch clause. Usually this is done by comparing RTTI (run time type identification) information which is associated with every type. RTTI is usually more comprehensive (and costly to compare) information than a simple int, as catching is polymorphic (eg it is possible to catch a reference to a base class, and that has to match all derived classes if they are thrown). This is one reason why lots of try/catch blocks in code is a danger sign -- the result is inefficient code that requires the compiler to do lots of things.

So, yes, there are overheads associated with exception handling. It would not be a good idea to throw exceptions when a simple break out of a loop will suffice (or, shock, horror a goto will do the trick). However, if it is necessary to have lots of functions calling each other, and having each function return if a callee returns an error code, there does come a point where exception handling is of comparable efficiency. And, if having a caller forget to check the return code from a callee can cause problems, exceptions are the safer approach --- it is not possible to accidentally cancel an exception.

Berto

Well i think, well an truly are gone the days of the silly conversations, damn these people no what they are talking about boo

__________________
"Put your hand on a hot stove for a minute, and it seems like an hour. Sit with a pretty girl for an hour, and it seems like a minute. THAT'S relativity."

- Albert Einstein

DaWei

I am currently writing a bucket sort app to correct my faux pas. It will move my C++ post from the C forum to here and move my inanities to the Lounge .

__________________
Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code.
Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

Ooble

Right... I need to rival that. I'm gonna make an Ooblot - it'll hang out on #programmingforums and talk crap. You won't be able to tell the difference.

__________________
Me :: You :: Them

DaWei

Talk crap, huh? I can name another forum it b'longs at .

__________________
Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code.
Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

grumpy

Oh? I thought a few people here had already done that

Ooble

Speaking of which, I'd like to see some of the newcomers on the IRC channel. it's at irc://irc.freenode.net/#programmingforums.

__________________
Me :: You :: Them