I'm working on an embedded platform, and I'm not comfortable adding 60k to my binary. There are arguments to avoid exceptions on embedded system anyway, but I think most of them are spurious. Exceptions make sense, but I can't justify the cost as it stands. I'm using gcc 4.6.3, maybe I'm missing an option, or maybe this is just the overhead of exceptions. I've tried -Os, and changing the exceptions to longjmp, but to no avail. I might have missed something.
Thanks for any insight.
As a rule of thumb, exception handling is extremely cheap when you don't throw an exception. It costs nothing on some implementations. All the cost is incurred when you throw an exception: that is, “normal code” is faster than code using error-return codes and tests. You incur cost only when you have an error.
It's an implementation detail for programming languages. E.g. C++ and Java have zero-cost exception handling.
C doesn't support exceptions. You can try compiling your C code as C++ with Visual Studio or G++ and see if it'll compile as-is. Most C applications will compile as C++ without major changes, and you can then use the try... catch syntax.
C++ exception handling is built upon three keywords: try, catch, and throw. throw − A program throws an exception when a problem shows up. This is done using a throw keyword. catch − A program catches an exception with an exception handler at the place in a program where you want to handle the problem.
At 1st, no!
Exception handling comes with some cost, mainly by requiring RTTI support primarily IMHO (didn't prove this experimentally so far). RTTI support will lead to some expense use of your code's text segment, especially if there are a lot of template instantiations (e.g. using STL templated classes/container-classes extensively with lot of various types).
On the other hand, compared to other possibilities to reduce e.g. newlib required implementations, the cost of 60k overhead is not so much.
You really should think twice about letting exception support go!
Funny enough, I've discussed this topic with my colleagues today, when we where facing an error that was obviously caused by an out of memory situation. The firmware in question (and it's OS bindings to FreeRTOS) don't support exceptions, but memory management implementation would trigger a processor exception, if you cannot acquire a certain amount of heap memory using new()
. This might happen using some STL induced algorithm, and you have no chance to intercept this using a try/catch
block on failure (e.g. usage of a simple std::vector
).
So you should decide how you might handle error situations, without using exceptions or not, and being sure to provide consistent behavior e.g. for usage of common STL patterns, etc., and weigh this out of the cost you pay for .text
section size.
You can turn off exceptions in GCC using -fno-exceptions
.
However, you can't have your cake and eat it too. Turning off exceptions means you can't catch them, and it will also break if you link against code compiled with exceptions on. But it does reduce the binary size as you intended.
Code without exceptions (but with the same level of error checking) is ugly as sin but it's a price you have to pay.
Lovely exception-free robust code example in C :)
error_t foo(void) {
if (!do_foo()) {
error_code = E_FOO;
goto bail;
}
if (!do_bar()) {
error_code = E_BAR;
goto bail;
}
/* repeat 100 times */
bail:
cleanup();
return error_code;
}
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With