6 ms·
On the other hand, once your embedded system is sufficiently large, people will want to use (and inevitably will use at some point) standard containers such as
by mmoll 3y ago
On the other hand, once your embedded system is sufficiently large, people will want to use (and inevitably will use at some point) standard containers such as std::string or std::vector. And without exceptions, all of those might invoke UB at any time (I have yet to see a standard library that understands and honors -fno-exceptions; usually they just drop all try-catch blocks and all throws)
- TwentyPosts 3y agoCould you elaborate on that? I'd love to see an example of this. Are you saying that even relatively simple code (using eg. std::vector) could easily cause UB if -fno-exceptions is enabled?
- accelbred 3y agoAny exception thrown with -fno-exceptions results in std::terminate. The behavior of std::terminate is unspecified.
- Karellen 3y agoThe behaviour is unspecified by the standard. Your compiler vendor has to pick a (reasonable) behaviour though and apply it consistently, and while they are not required to document it (IIRC - I think that's just for implementation-defined?) you can probably get them to tell you if you have a good support relationship with them. Or you can just figure out what the compiler does, and hope they don't change the behaviour too much with the next release :-)
- mmoll 3y agoMost standard containers have no way to communicate allocation failure to the caller in the absence of exceptions (think of constructors that take a size). Worse, the implementations I’ve seen would eventually call operator new, assuming it would throw if it fails. That is, subsequent code would happily start copying data to the newly created buffer, without any further tests if that buffer is valid. In the absence of exceptions, that won’t work.
- TwentyPosts 3y agoI guess my hope was that the program would just terminate immediately the instant it tries to throw an exception while -fno-exceptions is set, thus ideally preventing any further action from the program.
- isityouyesitsme 3y agoWhat does it mean for a safety-critical program to terminate? I suspect you do not want your car's brake controller to do this.
- tsimionescu 3y agoWell, what do you expect std::vector<T>::at() to do if the index is out of bounds and it can't throw exceptions? Or std::vector<T>::push_back() if it can't reallocate to a larger size? These are just some obvious cases. Not to mention that any use of operator new is UB if memory allocation fails and the system can't throw exceptions.
- TwentyPosts 3y agoWell, my hope was that we'd have a guarantee that the program is in fact just going to terminate, and the process is going to die. That's probably not great and might leave data in a bad shape, but it seems better than "undefined behavior" aka no guarantees whatsoever, no?
- oytis 3y agoIn safety critical embedded systems there is no such thing as "program just terminating". The program is the only software that is running on your device, and you need to degrade execution to some safe state no matter what. Every error should be processed, ideally right where it occurred (so I am not a great fan of exceptions either).
- andrepd 3y agoExactly. So you don't want `at()` either, you want a sane interface that would return an Option<T> for you to handle as you wish.
- tsimionescu 3y agoAt() with exceptions support is pretty much equivalent with a method returning an Option<T>. More precisely, it gives a superset of the functionality of returning Option<T>. If you declare the call site noexcept(), you should even get some compiler checking to make sure you handle the exception.
- 3y ago