CODEWITHSUNDEEP
c++exceptionarmcc
Earlz
Earlz

Reputation: 63935

Working with a C++ compiler that doesn't support exceptions?

I'm porting a C++ library to my mbed using the hosted mbed C++ compiler which is basically ARMCC with a configuration that you can't really change. One of the configuration options they decided on (for some unknown reason) is that exceptions are not supported. So a throw and a catch will yield compiler errors.

How exactly can you use the standard C++ library without exceptions? I use some vectors in my library. How do I know if the push_back function actually succeeded? Is there any standard way of knowing if an exception occurred or does it just do an exit(1) or something?

Upvotes: 6

Views: 3560

Answers (2)

stinky472
stinky472

Reputation: 6797

How exactly can you use the standard C++ library without exceptions? I use some vectors in my library. How do I know if the push_back function actually succeeded? Is there any standard way of knowing if an exception occurred or does it just do an exit(1) or something?

You're venturing into very restrictive territory once you disable exception handling in C++.

Some standard library implementations, like Dinkumware's, allows one to disable exceptions. There it's a matter of defining a macro, _HAS_EXCEPTIONS, as 0. STLPort has a similar convention with _STLP_USE_EXCEPTIONS=0.

However, there is no standard definition of what standard libraries should do when exceptions are disabled. Exception-handling, for the most part, is pretty much ingrained into the C++ language. Even dynamic_cast and operator new/new[] throw by default and those are not library features.

There's also a lack of a clear definition of what should happen even for the standard library implementations that don't throw. If a sequence push_back throws in the process of allocating more memory for that sequence, what should happen? Is the element simply not inserted? The standard interfaces of these sequences certainly tells us nothing about when such an error occurs.

Furthermore, a lot of C++ libraries in general will be using functions that do throw like operator new (and not the nothrow versions). As a result, we do venture into a lot of undefined behavior territory once we disable exceptions.

I once had to work in a company which forbid exception-handling since the senior programmers in charge were premature optimizers who preferred C and thought C++ was awful and inefficient (coincidentally, they wrote some of the most inefficient code on the team with a strong preference for linked lists as a default container which caused profiling hotspots to show up left and right due to the sheer number of tiny nodes being allocated/deallocated for everything, but that's another story).

With embedded systems, the argument against exception handling might be a bit stronger, but it does become difficult to rely on C++ in general without it. I think the best you can do without exception-handling is accept a crippled form of C++ without a lot of the standard library parts that throw unless you want to invest a lot of time trying to find workarounds and tricks specific to your particular standard library vendor which might be more trouble than it's worth.

Upvotes: 4

Alexey Frunze
Alexey Frunze

Reputation: 62106

They explain why it's not supported here:

The conventional wisdom (and the advice from the armcc compiler guys) is that the overhead of exceptions is pretty high and therefore not appropriate for this sort of domain. For now, we are therefore not supporting exceptions (it is hard to remove support, but easy to add it).

We'll definitely look at really understanding the space and time overheads at some point (mbed isn't really conventional, so perhaps exceptions are perfect!), but for now you'll have to stick to more conventional exception handling approaches.

And here:

We don't support exception handling in the compiler, and it is not planned to add it. But i'd be happy to hear about how you usually use them in your microcontroller applications, or your experiences! But for now, you will have to turn to more standard C solutions.

Based on this I can guess the exceptional situations would end up in std::terminate().

I don't think that not supporting exceptions is a legal option in C++ per the language standard. So, you should either make an experiment to see what happens when new or push_back() fails or ask the people behind the compiler.

Upvotes: 2

Related Questions