Exceptions vs. undefined behaviour
in [C++]
|
From: Johan Torp on 5 May 2008 23:43 IIRC, the standard library avoids throwing exceptions so that users which compile without exception support shall be able to use as much of the standard library as possible. Is this correct, incorrect or are there other motivations? Will this also be the case for the newly accepted libraries and for TR2? Will this "undefined behaviour"-strategy only apply to broken pre- conditions or will error codes and the like be used for reporting internal errors? Best Regards, Johan -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Lance Diduck on 6 May 2008 03:45 On May 6, 10:43 am, Johan Torp <johan.t...(a)gmail.com> wrote: > IIRC, the standard library avoids throwing exceptions so that users > which compile without exception support shall be able to use as much > of the standard library as possible. Is this correct, incorrect or are > there other motivations? > > Will this also be the case for the newly accepted libraries and for > TR2? > > Will this "undefined behaviour"-strategy only apply to broken pre- > conditions or will error codes and the like be used for reporting > internal errors? > > Best Regards, Johan Mostly, the standard library avoids throwing exceptions --or error checking in general--for performance reasons. This is true of the standard C library as well. The fact that standard C++ uses exceptions has little to do with it. Many good implementations of standard libraries have a checked mode, that will assert or throw or whatever based on invalid input, but the idea is to turn this off for production releases. The MSVC native library by default always has "secure" mode turned on, which does a LOT of checking, more than you could ever imagine. However, this is so egregiously slow that many developers spend a lot of time trying to figure out how to turn it off. (_SECURE_SCL=0 or somethign like that) TR2 follows the same guidelines as the std:: stuff, in that errors are reported by exception, unless they are the really stupid kind (like passing null pointers around, or getting iterator backward), then you get undefined behaviour. The good news is that much of the standard is being retrofitted with concepts, to help you avoid these really stupid error (and more subtle ones) at compile time, instead of waiting for a core dump. Lance -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Ron Natalie on 6 May 2008 03:46 Johan Torp wrote: > IIRC, the standard library avoids throwing exceptions so that users > which compile without exception support shall be able to use as much > of the standard library as possible. Is this correct, incorrect or are > there other motivations? No. There is no concept in C++ of running without fully supporting the language. The issue is less that the compiler doesn't support exceptions, but the code that is making use of the constructs aren't prepared to have interfaces throw exception (not exception safe). This is why there is frequently a way to alternatively use some flag other than handling errors with exceptions The general predisposition is that common errors, you will test for (without resorting to exceptions), for example iostream formatting error and end of file. Things that are likely to be rare and more difficult to recover (such as running out of memory) default to throwing exceptions. \ -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
|
Pages: 1 Prev: some quirks of Koenig lookup rule? Next: templates - partial specialization |