* Freddie Chopin: > Very nice that Moritz finally mentioned it (; The world of deep > embedded is usually forgotten by all the language committees and people > who are in charge.
That can only happen if the embedded people do not bother to show up in numbers. Of course the tools will move in different directions. > That's why the proposal by Herb is a real surprise and I really hope > it could be implemented someday. Would you use it if switching from -fno-exceptions to this new approach resulted in an immediate 20% code size increase, without actually using the new error handling feature at all? What about 10%? > The numbers above are maybe a bit too strict. A typical ARM Cortex-M > chip can have up to 2 MB of ROM and 512 kB of RAM, but I would say that > usually it has around 128-256 kB of ROM and somewhere around 16-64 kB > of RAM. The problem with C++ exceptions is that even in the most > trivial of the programs and even if you don't explicitly > use/catch/throw them, they instantly eat around 60 kB of ROM and quite > a lot of RAM. With some hacking you can get down to about 20 kB of ROM > (by overriding a lot of string formatting code and overriding > std::terminate()), but this is still too much for a feature you > actually don't use. It might still be interesting to contribute this somewhere. Is there any effort to bring down the table sizes and reduce the duplicated code in the cleanup paths? In most cases, it seems that the unwinder could actually run (the tail of) the successful return path and call _Unwinded_Resume itself, rather than having the compiler duplicate the cleanup code with an _Unwind_Resume at the end. The code optimizations would likely be needed for the flag-return error handling approach, too. Thanks, Florian
