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

Question

I port the C ++ library to my mbed using the hosted mbed C ++ compiler , which is basically ARMCC with a configuration that you cannot really change. One of the configuration options that they decided (for some unknown reason) is that exceptions are not supported. Thus, throw and catch will give compiler errors.

How exactly can you use the standard C ++ library without exception? I use some vectors in my library. How do I know if the push_back function was actually running? Is there any standard way to find out if an exception has occurred, or just do exit(1) or something else?

Answer 1

How exactly can you use the standard C ++ library without exception? I use some vectors in my library. How to find out if the push_back function really succeeded? Is there a standard way to find out if an exception has occurred, or does it just exit (1) or something else?

You go to very restrictive territory as soon as you turn off exception handling in C ++.

Some standard library implementations, such as Dinkumware, allow you to disable exceptions. There's a macro definition issue, _HAS_EXCEPTIONS, as 0. STLPort has a similar convention with _STLP_USE_EXCEPTIONS = 0.

However, the standard definition of standard libraries does not exist if exceptions are disabled. Exception handling, for the most part, is largely rooted in C ++. Even dynamic_cast and operator new/new[] throw by default, and these are not library functions.

There is also no clear definition of what should happen even for standard library implementations that are not thrown away. If the push_back sequence throws more memory for this sequence in the allocation process, what should happen? Is the item just not inserted? The standard interfaces of these sequences, of course, say nothing about when such an error occurs.

In addition, many C ++ libraries will generally use functions that are thrown as the new operator (and not the nothrow version). As a result, we move into many areas of undefined behavior after throwing exceptions.

I had to work for a company that forbade exception handling, because older programmers were premature optimizers who preferred C and thought that C ++ was horrible and inefficient (coincidentally they wrote some of the most inefficient codes in the team with a strong preference for linked lists as the default container, due to which the profiling hot spots were displayed on the left and right due to the fact that a huge number of small nodes were allocated / deallocated for everything, but this is different and thorium).

With embedded systems, the argument against exception handling can be a bit stronger, but without it it's hard to rely on C ++. I think the best thing you can do without exception handling is to take a crippled C ++ form without a lot of standard library parts that throw if you don't want to invest a lot of time trying to find workarounds and tricks specific to your a particular vendor of a standard library that may be more of a problem than it costs.

Answer 2

They explain why he does not support here :

The usual wisdom (and advice from armcc compilers) is that the overhead of exceptions is quite high and therefore not suitable for this kind of domain. At the moment, we are therefore not supporting exceptions (it is difficult to remove support, but it is easy to add it).

We'll definitely take a look at understanding space and time overhead at some point (mbed is actually not ordinary, so maybe the exceptions are perfect!), But for now you will have to stick to more conventional exception handling methods.

And here :

We do not support exception handling in the compiler, and it is not planned to add it. But I would be glad to hear about how you usually use them in the applications of your microcontroller or in your impressions! But for now, you'll have to turn to more standard C solutions.

Based on this, I can guess that exceptions would end in std::terminate() .

I do not think that non-supporting exceptions are a legitimate option in C ++ by language standard. So, you should either do an experiment to find out what happens when new or push_back() fails, or ask the people behind the compiler.