With "-fno-exceptions", what happens to the "new T"?

Question

I was wondering if new T throw bad_alloc if I compile my program using the -fno-exceptions option to disable exception handling?

Or does the compiler (GCC and clang support this option) implicitly convert the use of new T to new (nothrow) T ?

Answer 1

I can’t give a final answer to all the benefits around -fno-exceptions, just observing on a 32-bit Linux machine, gcc 4.5.1 - bad_alloc is reset with -fno-exceptions

 [21:38:35 1 ~/tmp] $ cat bad_alloc.cpp int main() { char* c = new char[4000000000U]; } [21:38:58 1 ~/tmp] $ g++ bad_alloc.cpp [21:39:06 1 ~/tmp] $ ./a.out terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc Aborted [21:39:07 1 ~/tmp] $ g++ -fno-exceptions bad_alloc.cpp [21:39:16 1 ~/tmp] $ ./a.out terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc Aborted 

Answer 2

As I understand it, operator new is defined by libstdC ++. If you now compile your own code with -fno-exceptions , you cannot catch any exceptions, but you will still refer to the regular version of libstdC ++ that throws an exception.

So yes, new T will throw an exception even with -fno-exception .

However, if you compiled libstdC ++ with -fno-exception , things will be different. Now new T cannot throw an exception, but if I read the libstdC ++ user manual , it will call abort() instead.

It seems that if you want your new T return NULL on error, the only way is to explicitly specify nothrow ...

Answer 3

This is not a definitive answer, but the GCC Guide (see "Doing Without") has the following:

Before describing in detail the library support for -fno-exceptions , first pay attention to the things that were lost when this flag is used: it throws exceptions while trying to go through the compiled code with -fno-exceptions , regardless of whether this code has any attempt or trick it builds . If you may have some code that throws, you should not use -fno-exceptions .

As I read this, you may need to explicitly request the full version of new .

Answer 4

In many exception handling systems, if the foo subroutine calls a bar, which in turn throws a moo, and moo throws an exception, the only way this exception can purely return to foo is if bar "has a code to handle the exception. Even if the “bar” allows to exclude the distribution of the non-displayable, it, as a rule, must ensure that its local variables are correctly destroyed before the execution is allowed to leave the scope. To do this, you need to add additional code to "bar"; on most systems, part of this code must be executed even if no exception is thrown.

BTW, on some ARM processors, such as Cortex M3, or as Arm7, working in ARM mode, if the caller will also work in ARM mode, you can allow exceptions without any cost to the execution time. Returning the “normal” subroutine goes to LR + 4 (four bytes per normal return address) and has an exclusive output in LR (which would then be a 4-byte branch instruction). However, this behavior will be contrary to the usual practice in ARM, and such a design will not be well ported to the Cortex M0.