C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Everything you wanted to know about implementing exception h Goto page 1, 2  Next          C++Talk.NET Forum Index -> C++ Language (Moderated) View previous topic :: View next topic   Author Message White Wolf Guest Posted: Sun Mar 06, 2005 6:36 pm    Post subject: Everything you wanted to know about implementing exception h Hi, (My questions re at the end of the post. SO please read it through, before you start answering it. Thank you.) This post and some of its questions are (primarily) for Bjarne Stroustrup, but anyone with good ideas may and should join. :-) My copy of [TCPL-SE] say in 14.8 (page 381, last paragraph): "In principle, exception handling can be implemented so that there is no runtime overhead when no exception is thrown." This is nice, I can even see it if I test it. The text goes on: "In addition, this can be done so that throwing an exception isn't all that expensive compared to calling a function." Sounds good. "Doing so without adding significant memory overhead while maintaining compatibility with C calling sequences, debugger conventions, etc., is possible, but hard." OK. From the above I am only interested in "possible". Now the second sentence I have quoted compares throwing an exception to calling a function. I have possibly cheated in my little test executable, but what I see, is that (with the compilers I have tried) throwing an exception is a lot more expensive than calling a function. This is of course the implementation I have tried. But what I have found sounds very different from what [TCPL-SE] says. In my testing I had 5 do-nothing/void functions, calling each other. They have been in different translation units, inlining could not (and did not) happen. The difference between the two tested scenario was that in the throw case the 5th (deepest) function threw a string literal (which in turn means throwing a pointer, one of the cheapest possible types). In one case it was 4 orders of magnitude slower (10000 times) to "return" using throw, in another test, I have measured 5 orders of magnitude difference. I know that my test was/is the least fair possible (towards exception handling mechanisms), but if exception handling costed no more than calling a function, the difference between the two test runs should have been not much more than 20% (since I had 5 function calls). But since my calls took no arguments, I could accept even a 1 to 2 difference, but the difference was more than 1 to 1000 in each case. The above suggests, that the implementation of exceptions in those compilers lacks a lot, compared to the ideal described in the book. Have these statements (of the book) been proven to be too optimistic? If not, why do we have compilers (5 years after the publication of the Special Edition and more after 3rd Edition), which give serious runtime penalties for throwing an exception? What are those implementation technologies Mr. Stroustrup refers to? Are they secret? Patented? Or (some) compiler developers consider exceptions to be a mainly unused feature, so they do not invest in making it faster? I am asking these, because right now, this is an evil circle. Many people do not use exceptions, because they are slow. Implementers do not make it faster, because people are not using them. The big problems is (with the compilers I have tested) that using exceptions to report *any* error triggered by the outside world equals to enabling a quick and easy denial of service attack towards that software. Since it will go 1000+ times slower due to the exceptions, so all the attacker needs to know, is how to trigger an exception-throw in the software. === [TCPL-SE] Bjarne Stroustrup The C++ Programming Language, Special Edition ISBN 0-201-70073-5 First printing, January 2000 -- WW aka Attila ::: Statistics are like bikinis. What they conceal is more important than what they reveal. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Marco Manfredini Guest Posted: Mon Mar 07, 2005 11:02 pm    Post subject: Re: Everything you wanted to know about implementing excepti White Wolf wrote: Quote: My copy of [TCPL-SE] say in 14.8 (page 381, last paragraph): "In principle, exception handling can be implemented so that there is no runtime overhead when no exception is thrown." This is nice, I can even see it if I test it. The text goes on: "In addition, this can be done so that throwing an exception isn't all that expensive compared to calling a function." Sounds good. And what does it mean? Since the paragraph does not tell us *which* function it compares the costs of throwing an exception to (an empty function? the function that computes the first ascii encoded occurrence of hamlet in the binary representation of PI?), we must conclude that instead it talks about the costs of issuing the function call / throwing the exception themselves. So for me it says, that the code sequence that has to be generated for "throw 0;" is very similar in cost to the code sequence for "somefunction(0)" - throwing an exception does not bloat your code - but it does not say anything about processing the exception. Quote: The big problems is (with the compilers I have tested) that using exceptions to report *any* error triggered by the outside world equals to enabling a quick and easy denial of service attack towards that software. Since it will go 1000+ times slower due to the exceptions, so all the attacker needs to know, is how to trigger an exception-throw in the software. What kind of service do have in mind that would suffer from burning 50000 cycles in stack unwinding for a failing request, in particular with regard to the cycles saved because explicit checks for the unexpected aren't required anymore? Marco [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top wkaras@yahoo.com Guest Posted: Mon Mar 07, 2005 11:34 pm    Post subject: Re: Everything you wanted to know about implementing excepti White Wolf wrote: Quote: Hi, (My questions re at the end of the post. SO please read it through, before you start answering it. Thank you.) This post and some of its questions are (primarily) for Bjarne Stroustrup, but anyone with good ideas may and should join. You may wish to notify Dr. Stroustrup directly via e-mail that you are posing this question. His web page is http://www.research.att.com/~bs/homepage.html Quote: My copy of [TCPL-SE] say in 14.8 (page 381, last paragraph): "In principle, exception handling can be implemented so that there is no runtime overhead when no exception is thrown." I would guess this refers to the fact that the return address that is pushed onto the stack whenever a function is called is all the information that is strictly necessary to destroy (as necessary) active objects in the calling function when the called function throws an execption (or calls a function that throws an exception). The g++ implementation of excecptions (I believe) takes advantage of this fact, so there is no (time) overhead in g++ object code when exceptions are not thrown. I believe that VC++ does NOT use this optimization, therefore enabling exceptions causes runtime overhead even if no exception is ever thrown. I don't understand the rational behing VC++'s implementation of exceptions. Maybe it's because Bill Gates feels that anyone who can't see that Visual Basic is the most perfect programming language possible deserves to suffer. Quote: This is nice, I can even see it if I test it. The text goes on: "In addition, this can be done so that throwing an exception isn't all that expensive compared to calling a function." Sounds good. I'd like to see some elaboration on this too. Without further enlightenment, I would only go so far as to say that throwing an exception is likely to be faster and more compact than the code you'd write to avoid thowing the exception. Quote: "Doing so without adding significant memory overhead while maintaining compatibility with C calling sequences, debugger conventions, etc., is possible, but hard." OK. From the above I am only interested in "possible". One problem with exceptions is that functions are assumed to thow them by default. This causes the compliler to generate alot of "dead" handling code that is never executed. It seems that, in many practical situations, the empty "thows()" specification is too much of a hassle to use properly. I suppose that, in theory, the linker could make an apocalyptic final pass over the entire executable to remove the unecessary handling code. But I'd be very surprised if there's a linker that actually does this. It might not be a bad idea for compiler makers to add a command line option to make "throws nothing" the default. Explitly stating "thow(...)" should mean that a function must be assumed to throw anyting (if it doesn't already). I could see how you could dove-tail the "normal" end-of-block instance-destruction code with the exception-case destruction code (to reduce memory overhead). But it seems like there'd be a small excecution time penalty in the non-exeception case (to test and branch at the end of the destruction code). Then there's the associative lookup table from return addresses to entry points for destruction code. Seems like the size of this could be "significant". We also should keep some perspective here. How much code-bloat is caused by our laziness about dividing object code into the smallest independently-linkable modules possible? You see alot of this even in OS and other third-party libraries, with enough sales volume so there's little excuse for it. Quote: ... [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Eugene Gershnik Guest Posted: Tue Mar 08, 2005 11:02 am    Post subject: Re: Everything you wanted to know about implementing excepti [email]wkaras (AT) yahoo (DOT) com[/email] wrote: Quote: I believe that VC++ does NOT use this optimization, therefore enabling exceptions causes runtime overhead even if no exception is ever thrown. I don't understand the rational behing VC++'s implementation of exceptions. Maybe it's because Bill Gates feels that anyone who can't see that Visual Basic is the most perfect programming language possible deserves to suffer. You may want to browse this group again to discover all these posts from people who try to link C program with C++ library on various flavors of Unix only to discover that C++ exceptions stop working _within_ C++ library. This doesn't happen with VC precisely because people who Bill Gates employs to create it made a right choice and rely on system-wide mechanism. As it stands now all these "fast" C++ exception implementations you seem to like do not allow me to do something trivial like writing an Apache module in modern C++. With VC I can safely call C++ code even from Visual Basic. As for denial of service attacks it is very naive to expect to shield oneself from them by making exceptions a little bit faster. In general there is no known defense against DoS and the best the software can hope for is to completely disable an attacked module. -- Eugene [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Alf P. Steinbach Guest Posted: Tue Mar 08, 2005 11:08 am    Post subject: Re: Everything you wanted to know about implementing excepti * [email]wkaras (AT) yahoo (DOT) com[/email]: Quote: * White Wolf wrote: "In principle, exception handling can be implemented so that there is no runtime overhead when no exception is thrown." I would guess this refers to the fact that the return address that is pushed onto the stack whenever a function is called is all the information that is strictly necessary to destroy (as necessary) active objects in the calling function when the called function throws an execption (or calls a function that throws an exception). The g++ implementation of excecptions (I believe) takes advantage of this fact, so there is no (time) overhead in g++ object code when exceptions are not thrown. I believe that VC++ does NOT use this optimization, therefore enabling exceptions causes runtime overhead even if no exception is ever thrown. I don't understand the rational behing VC++'s implementation of exceptions. Visual C++ integrates Windows SEH exceptions, the Windows feature corresponding to Unix/C signals, with C++ exceptions. If Visual C++ does not optimize like g++ does then that is most likely the cause. From a theoretical perspective it's very nice to have that integration, e.g. one can get reliable null-pointer C++ exceptions and floating point C++ exceptions, but in practice it's not very useful because very very few APIs use SEH, null-pointer errors are logic errors, and non-signalling floating point operations with NaNs are usually preferable to signalling ones (I hope I got the terminology right here, someone please correct if wrong). -- A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top kanze@gabi-soft.fr Guest Posted: Tue Mar 08, 2005 11:16 am    Post subject: Re: Everything you wanted to know about implementing excepti [email]wkaras (AT) yahoo (DOT) com[/email] wrote: Quote: White Wolf wrote: Hi, (My questions re at the end of the post. SO please read it through, before you start answering it. Thank you.) This post and some of its questions are (primarily) for Bjarne Stroustrup, but anyone with good ideas may and should join. :-) You may wish to notify Dr. Stroustrup directly via e-mail that you are posing this question. His web page is http://www.research.att.com/~bs/homepage.html I'm pretty sure that Stroustrup reads this forum, and some of the people who work with him contribute here regularly. So I have no doubt that he is aware of Attila's question. Of course, if Attila did want a personal response from Stroustrup, instead of our speculations, he probably should have email'ed it to him. Quote: My copy of [TCPL-SE] say in 14.8 (page 381, last paragraph): "In principle, exception handling can be implemented so that there is no runtime overhead when no exception is thrown." I would guess this refers to the fact that the return address that is pushed onto the stack whenever a function is called is all the information that is strictly necessary to destroy (as necessary) active objects in the calling function when the called function throws an execption (or calls a function that throws an exception). The g++ implementation of excecptions (I believe) takes advantage of this fact, so there is no (time) overhead in g++ object code when exceptions are not thrown. I believe that VC++ does NOT use this optimization, therefore enabling exceptions causes runtime overhead even if no exception is ever thrown. I don't understand the rational behing VC++'s implementation of exceptions. Maybe it's because Bill Gates feels that anyone who can't see that Visual Basic is the most perfect programming language possible deserves to suffer. More likely simple historical reasons. I doubt that Bill Gates makes any decisions concerning how things are implemented in the C++ compiler. Quote: This is nice, I can even see it if I test it. The text goes on: "In addition, this can be done so that throwing an exception isn't all that expensive compared to calling a function." Sounds good. I'd like to see some elaboration on this too. Without further enlightenment, I would only go so far as to say that throwing an exception is likely to be faster and more compact than the code you'd write to avoid thowing the exception. It definitly isn't faster with the existing implementations I deal with. And it's only more compact because the compiler generates the exception handling code in every case, even if I don't use exceptions. If the throw is deeply nested from the catch, it is likely that the code is faster in the normal case, when I don't throw, because I don't have all of the tests in the intermediate functions. But that's only the case if I don't throw. I have yet to see a case in practice, however, where the performance was an issue one way or the other. Use exceptions when they are the cleaner solution. Use something else when it is cleaner. Don't worry about performance until you have to. (If you are using exceptions, and the profiler says they have to go, you've got your work cut out for you. But I find it difficult to imagine such a case.) Quote: "Doing so without adding significant memory overhead while maintaining compatibility with C calling sequences, debugger conventions, etc., is possible, but hard." OK. From the above I am only interested in "possible". One problem with exceptions is that functions are assumed to thow them by default. This causes the compliler to generate alot of "dead" handling code that is never executed. So. Correctly done, the "dead" code won't even be loaded into memory until (or unless) an exception is thrown. (But I don't know of a compiler that goes this far yet, although on most systems, it is fairly simple to implement.) Quote: It seems that, in many practical situations, the empty "thows()" specification is too much of a hassle to use properly. I suppose that, in theory, the linker could make an apocalyptic final pass over the entire executable to remove the unecessary handling code. All of the "linkers" I know that are that sophisticated are more concerned with speed than with code bloat, and probably don't bother with removing unused tables. Quote: But I'd be very surprised if there's a linker that actually does this. It might not be a bad idea for compiler makers to add a command line option to make "throws nothing" the default. Which could more than a few problems with headers from other projects. Don't forget, too, that throw() doesn't mean that the function can't throw. It means that no exceptions will propagate out. Depending on how the compiler implements it, it could mean an implicite try... catch; on some compilers, it could cost more than supposing throw anything. Quote: Explitly stating "thow(...)" should mean that a function must be assumed to throw anyting (if it doesn't already). I could see how you could dove-tail the "normal" end-of-block instance-destruction code with the exception-case destruction code (to reduce memory overhead). But it seems like there'd be a small excecution time penalty in the non-exeception case (to test and branch at the end of the destruction code). Then there's the associative lookup table from return addresses to entry points for destruction code. Seems like the size of this could be "significant". A couple of pointers (maybe 8 bytes) per function ? For some embedded systems, it could be critical. For a general purpose processor, I doubt it. Quote: We also should keep some perspective here. How much code-bloat is caused by our laziness about dividing object code into the smallest independently-linkable modules possible? None, since we only put one function in each source file:-). Seriously, of course, that was the policy back in the old days, and IMHO, it is still the policy for general purpose, low-level classes, which are likely to be linked into many different applications. If the class is only going to be used in one application, of course, the answer is to not even write functions which won't be called. Of course, if the functions are virtual, the linker will pull them all in anyway, so there's no point in this there. Quote: You see alot of this even in OS and other third-party libraries, with enough sales volume so there's little excuse for it. The question is always, what creates the sales volume. Currently, I'd say that ease of use primes over absolute performance (or conformity). So that's what the vendors spend most of their effort on. -- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top wkaras@yahoo.com Guest Posted: Tue Mar 08, 2005 9:11 pm    Post subject: Re: Everything you wanted to know about implementing excepti [email]kanze (AT) gabi-soft (DOT) fr[/email] wrote: Quote: wkaras (AT) yahoo (DOT) com wrote: .... I don't understand the rational behing VC++'s implementation of exceptions. Maybe it's because Bill Gates feels that anyone who can't see that Visual Basic is the most perfect programming language possible deserves to suffer. More likely simple historical reasons. I doubt that Bill Gates makes any decisions concerning how things are implemented in the C++ compiler. .... Sorry, forgot the . I find it hard not to conclude that Microsoft tries to force the use of MS proprietary languages and/or MS proprietary extensions to ISO C++, and that this is a policy approved by the big guy himself. But I guess this isn't an issue with regard to the implementation of exceptions, because I think it's equally bad in VB and C#. Even if you want to integrate arithmetic overflow or async events into the exception concept, you can still unwind the stack using just the return addresses that are in the stack anyway. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top David Abrahams Guest Posted: Wed Mar 09, 2005 11:33 pm    Post subject: Re: Everything you wanted to know about implementing excepti "Eugene Gershnik" <gershnik (AT) hotmail (DOT) com> writes: Quote: wkaras (AT) yahoo (DOT) com wrote: I believe that VC++ does NOT use this optimization, therefore enabling exceptions causes runtime overhead even if no exception is ever thrown. I don't understand the rational behing VC++'s implementation of exceptions. Maybe it's because Bill Gates feels that anyone who can't see that Visual Basic is the most perfect programming language possible deserves to suffer. You may want to browse this group again to discover all these posts from people who try to link C program with C++ library on various flavors of Unix only to discover that C++ exceptions stop working _within_ C++ library. This doesn't happen with VC precisely because people who Bill Gates employs to create it made a right choice and rely on system-wide mechanism. As it stands now all these "fast" C++ exception implementations you seem to like do not allow me to do something trivial like writing an Apache module in modern C++. With VC I can safely call C++ code even from Visual Basic. The one mentioned, the current G++ spec, is a system-wide standard. The spec started as the IA-64 ABI and morphed into something more generally named -- I forget what. http://www.realitydiluted.com/mirrors/reality.sgi.com/dehnert_engr/cxx/cxx-summary.html There are probably better links for this. But having a system-wide standard is no help if the code making the calls across language boundaries is not written to expect unwinding. I don't know if VB has a representation of exceptions, but native 'C' doesn't. If you just write straightforward 'C' code, any unwinding is likely to wreak havoc with program invariants. -- Dave Abrahams Boost Consulting www.boost-consulting.com [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Eugene Gershnik Guest Posted: Thu Mar 10, 2005 9:27 am    Post subject: Re: Everything you wanted to know about implementing excepti David Abrahams wrote: Quote: But having a system-wide standard is no help if the code making the calls across language boundaries is not written to expect unwinding. I don't know if VB has a representation of exceptions, but native 'C' doesn't. If you just write straightforward 'C' code, any unwinding is likely to wreak havoc with program invariants. You missed my point. Suppose you have situation where a main() compiled and linked in C calls foo() from a [shared] library compiled with C++. foo() can be something trivial like this foo() { try { throw 1; } catch(int) { } } The exception stays within C++ which is supposed to handle it. What often happens on gcc/Sun Forte is that the catch doesn't catch and the program crashes. Presumably some tables are not pulled in by the linker or something similar happens. I don't really know and honestly don't care. This situation simply cannot happen on Win32/VC. What you mention is the situation where a C++ exception "flies through" another language. Since both Microsoft C (__try/__except/__finally) and Visual Basic (ON ERROR) understand OS exceptions they actually _can_ do something intelligent and well defined about them such as cleaning up their state. Note that again relying on system-wide mechanism allows to do things that are simply impossible in "each language is a black box" world. Having said all that I must add that the decision of having catch(...) catch _all_ OS exceptions was a mistake that really spoils the whole thing. -- Eugene [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top David Abrahams Guest Posted: Thu Mar 10, 2005 8:30 pm    Post subject: Re: Everything you wanted to know about implementing excepti "Eugene Gershnik" <gershnik (AT) hotmail (DOT) com> writes: Quote: David Abrahams wrote: But having a system-wide standard is no help if the code making the calls across language boundaries is not written to expect unwinding. I don't know if VB has a representation of exceptions, but native 'C' doesn't. If you just write straightforward 'C' code, any unwinding is likely to wreak havoc with program invariants. You missed my point. Suppose you have situation where a main() compiled and linked in C calls foo() from a [shared] library compiled with C++. foo() can be something trivial like this foo() { try { throw 1; } catch(int) { } } The exception stays within C++ which is supposed to handle it. What often happens on gcc/Sun Forte is that the catch doesn't catch and the program crashes. Presumably some tables are not pulled in by the linker or something similar happens. I don't really know and honestly don't care. Sounds like someone forgot to link in the C++ runtime. Oops, sorry, you don't care ;-) Quote: This situation simply cannot happen on Win32/VC. It's poor QOI, but one should not have to pay for MS's inefficient exception-handling (in fact, on 64-bit windows they use a "zero overhead" exception mechanism), or even any special language integration to make it better. I don't really think the fact that you're having problems on one platform has anything fundamental to do with MS's EH strategy ;-) -- Dave Abrahams Boost Consulting www.boost-consulting.com [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Dylan Nicholson Guest Posted: Fri Mar 11, 2005 12:46 am    Post subject: Re: Everything you wanted to know about implementing excepti "Eugene Gershnik" <gershnik (AT) hotmail (DOT) com> wrote Quote: David Abrahams wrote: But having a system-wide standard is no help if the code making the calls across language boundaries is not written to expect unwinding. I don't know if VB has a representation of exceptions, but native 'C' doesn't. If you just write straightforward 'C' code, any unwinding is likely to wreak havoc with program invariants. You missed my point. Suppose you have situation where a main() compiled and linked in C calls foo() from a [shared] library compiled with C++. foo() can be something trivial like this foo() { try { throw 1; } catch(int) { } } The exception stays within C++ which is supposed to handle it. What often happens on gcc/Sun Forte is that the catch doesn't catch and the program crashes. Presumably some tables are not pulled in by the linker or something similar happens. I don't really know and honestly don't care. I've definitely had this occur - I never figured out it had anything to do with linking to C code though. I think in the end we had to give up using exceptions. That was some time ago though, using compilers that would now be near on 15 years old - I'd like to think the situation had improved since then. Quote: This situation simply cannot happen on Win32/VC. What you mention is the situation where a C++ exception "flies through" another language. Since both Microsoft C (__try/__except/__finally) and Visual Basic (ON ERROR) understand OS exceptions they actually _can_ do something intelligent and well defined about them such as cleaning up their state. Note that again relying on system-wide mechanism allows to do things that are simply impossible in "each language is a black box" world. OT I know, but does ON ERROR really catch OS exceptions? Can it catch C++ exceptions? As far as C++ exceptions passing through C code, this is no worse than signals being raised and other such OS/hardware interrupts. Most C code isn't really written to cope well with possible interruptions in the flow of execution, but on the other hand, usually the worst that will happen is a memory leak or a dangling file handle. In a server application over a long period of time this *can* be a real problem, but I would say the benefits of being able to allow C++ exceptions to prematurely abort the execution of C functions outweigh this potential pitfall - I've made use of it more than once (the C code wasn't mine, but I could analyse what the consequences would be). Quote: Having said all that I must add that the decision of having catch(...) catch _all_ OS exceptions was a mistake that really spoils the whole thing. Hmm, again OT...but while I can accept the purist's POV on this one, the reality is quite different - being able to rely on a catch(...) for all those nasty OS exceptions out of your control (like bugs in ODBC drivers and the like) has saved me more times than I care to count! Presumably the various ABI's for C++ that have been published describe how exceptions are passed and should be caught. Does any know how many C++ compilers don't rely on at least some OS (or hardware) support for C++ exceptions? Do they still allow exceptions to propogate across shared (dynamically loaded) library boundaries? Even if the library gets unloaded during stack unwinding? (I think this can be a problem even under Windows.) [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Eugene Gershnik Guest Posted: Fri Mar 11, 2005 11:52 am    Post subject: Re: Everything you wanted to know about implementing excepti David Abrahams wrote: Quote: Sounds like someone forgot to link in the C++ runtime. Oops, sorry, you don't care Who could it be? The author of a web server written in C that calls dlopen()? The author of dlopen()? Or the author of C++ shared library that is successfully loaded by dlopen()? Jokes aside I know how to solve this problem but all the solutions are ugly. Quote: This situation simply cannot happen on Win32/VC. It's poor QOI, but one should not have to pay for MS's inefficient exception-handling (in fact, on 64-bit windows they use a "zero overhead" exception mechanism), or even any special language integration to make it better. Perhaps. But before optimizing speed the solution must be *usable*. So far the alternatives to Win32/VC approach I have seen (and I haven't seen what they did for Itanium) were worse from usability perspective. As for EH speed it is a nice to have feature. If a code throws exceptions in a tight loop it has more serious problems. Quote: I don't really think the fact that you're having problems on one platform has anything fundamental to do with MS's EH strategy Me too Still I think given the state of technology in 1993[1] their choice was better than those made by other vendors I know. -- Eugene [1] - My guess of when C++ EH was implemented in VC based on some magic numbers it uses [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top David Abrahams Guest Posted: Sat Mar 12, 2005 1:47 am    Post subject: Re: Everything you wanted to know about implementing excepti "Eugene Gershnik" <gershnik (AT) hotmail (DOT) com> writes: Quote: David Abrahams wrote: Sounds like someone forgot to link in the C++ runtime. Oops, sorry, you don't care ;-) Who could it be? The author of a web server written in C that calls dlopen()? The author of dlopen()? Or the author of C++ shared library that is successfully loaded by dlopen()? Jokes aside I know how to solve this problem but all the solutions are ugly. This situation simply cannot happen on Win32/VC. It's poor QOI, but one should not have to pay for MS's inefficient exception-handling (in fact, on 64-bit windows they use a "zero overhead" exception mechanism), or even any special language integration to make it better. Perhaps. But before optimizing speed the solution must be *usable*. So far the alternatives to Win32/VC approach I have seen (and I haven't seen what they did for Itanium) Same ABI as G++ on Linux. Quote: were worse from usability perspective. As for EH speed it is a nice to have feature. If a code throws exceptions in a tight loop it has more serious problems. I don't really think the fact that you're having problems on one platform has anything fundamental to do with MS's EH strategy ;-) Me too Still I think given the state of technology in 1993[1] their choice was better than those made by other vendors I know. I believe that. Thought I think Metrowerks was doing it right by then. -- Dave Abrahams Boost Consulting www.boost-consulting.com [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Eugene Gershnik Guest Posted: Sat Mar 12, 2005 2:07 am    Post subject: Re: Everything you wanted to know about implementing excepti Dylan Nicholson wrote: Quote: "Eugene Gershnik" <gershnik (AT) hotmail (DOT) com> wrote in message news:_4-dnWU8a6o4bbLfRVn-ow (AT) speakeasy (DOT) net... I've definitely had this occur - I never figured out it had anything to do with linking to C code though. Usually it is either linking with C or with code compiled with different C++ compiler. I hit this problem every time I work with "plugin architectures" on Unix. Quote: I think in the end we had to give up using exceptions. That was some time ago though, using compilers that would now be near on 15 years old - I'd like to think the situation had improved since then. Most recently I've seen it on Sun Forte 6 and 7. Quote: What you mention is the situation where a C++ exception "flies through" another language. Since both Microsoft C (__try/__except/__finally) and Visual Basic (ON ERROR) understand OS exceptions they actually _can_ do something intelligent and well defined about them such as cleaning up their state. Note that again relying on system-wide mechanism allows to do things that are simply impossible in "each language is a black box" world. OT I know, but does ON ERROR really catch OS exceptions? Can it catch C++ exceptions? IIRC yes (if it can do former it can do later). It wouldn't be able to do anything with C++ exception _object_ or unwind C++ stack though. Quote: Having said all that I must add that the decision of having catch(...) catch _all_ OS exceptions was a mistake that really spoils the whole thing. Hmm, again OT...but while I can accept the purist's POV on this one, the reality is quite different - being able to rely on a catch(...) for all those nasty OS exceptions out of your control (like bugs in ODBC drivers and the like) has saved me more times than I care to count! You have __try/__except/__finally extensions for that which do not perform unwinding and also give you information about what really happened. This is not purism vs. practicality. Trying to perform unwinding after an OS exception such as bad pointer can be suicidal ;-) Quote: Even if the library gets unloaded during stack unwinding? (I think this can be a problem even under Windows.) It is. Actually this makes using C++ exceptions in kernel mode very problematic since catching code may be paged out. -- Eugene [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Jan Becvar Guest Posted: Mon Mar 14, 2005 1:27 pm    Post subject: Re: Everything you wanted to know about implementing excepti Quote: Usually it is either linking with C or with code compiled with different C++ compiler. I hit this problem every time I work with "plugin architectures" on Unix. Some time ago I had problems looking similar like those you describe here. It was under Linux, the code with exceptions was compiled under Kylix, and it was using a library (dynamically, dlopen()) compiled with gcc. In a previous post you have mentioned that you know some (ugly) solutions. Can you please give me some hints? Any additional info about the problem is welcome. Thanks, Jan. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ Language (Moderated) All times are GMT Goto page 1, 2  Next Page 1 of 2   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.