[prev] [thread] [next] [lurker] [Date index for 2007/01/29]
Joshua Rodman wrote: > On Mon, Jan 29, 2007 at 11:13:35AM +0200, Yossi Kreinin wrote: > > Of cousrse, I dont' believe this amount of overhead matters to most > people at all anymore. But I know in some circumstances it is > completely unacceptable. Sure, I use exceptions in desktop applications because I don't care about the overhead there. > > What is a real pisser is that you claim you have to manually tell the > compiler to turn it off globally. If you don't use the exceptions > feature in any of your code, can't the compiler figure out to make this > optimization? A lot of horror related to C/C++ implementation/instrumentation comes from the fact that in practice, your source code must be built to interact with code built by someone else. For example, you might want to compile your application with padding of uninitialized memory between structure members so that something like valgrind has more chances to spot buffer overflows (a random example - the first thing that came to mind). You can't do that since calls to functions built by someone else or written in assembly won't work. This is why things like garbage collection remain theoretical. The same is true for exceptions - you never know if a function built by someone else throws one, so you must be prepared for stack unwinding. Another horrible thing about C++ is that the calling conventions are not portable across compilers (C conventions largely are). The different mangling conventions of different compilers you can work around using extern "C". But different stack unwinding conventions you can not work around that easily. That aside, C/C++ compilers rarely do anything at all at link time - they emit assembly code and walk away and the linker links it without knowing anything about C/C++. The linker doesn't know about exceptions so it can't make decisions depending on whether some of the code throws something or not, even if it does see all relevant code (no dynamic loading, etc.) Of course a lot of these problems are hard to solve. LLVM is one serious attempt - it stores bytecode in portable IR and can do just-in-time compilations, hairy link-time things (I think gcc 4 is strong there, too), etc. But most C/C++ platforms are simpler than that, and the big problem is having to assume the lowest common denominator. One great thing about JVM, .NET, etc. is that you can analyze & instrument code built by someone else. Of course when C was designed such approach wasn't very practical even without JITting - you wouldn't like to spend time on first compiling code to IR and then compile the IR to native bytecode. The thing is that in C there's a much smaller gap between theory and practice. In C++, templates are theoretically much better than macros, in practice they take ages to compile. Overloading is theoertically wonderful because it gives you compile-time polymorhpism and what-not, in practice go figure who calls what (grep won't work and IDEs won't either), and there's no portable mangling convention (how hard would that be?). Exceptions are theoretically zero-overhead, in practice again no portable unwinding conventions, and huge data overhead and almost always small run-time overhead, and once an exception is thrown you lose the call stack, and, and, and... > > So long as you stop caring about performance nearly entirely, I think > there are many such platforms available. > In these cases the first thing I do is choose a different language, one that is willing to at least try not to dump core.There's stuff above here
Generated at 23:01 on 06 Feb 2007 by mariachi 0.52