Can you guarantee the code in the C++ stdlib will not throw exceptions? Scratch that, the stdlib API is unusable with exceptions disabled. None of the functions return an error code.
The C++ stdlib (aka STL) is 100% usable without exceptions. This is deliberate: major players and code bases disable exceptions, including Google, LLVM, Firefox, so it has to work and work well. And disabling exceptions is easy, simply pass `-fno-exceptions` to the compiler.
Fallible C++ functions do return an error code. errno is part of C++.
wouldn't say 100%, and -fno-exceptions does not disable exception propagation, it only prevents you from having the keywords "throw / try / catch" in your code. It's because it's not a C++ feature but a platform one which C++ leverages - when GCC compiles C code for instance it makes sure that their stack can be unwound in case there would be a callback implemented in C++ which would throw an exception (and because this is also a generally useful ability to have).
If you use the stdlib it will still throw (but disabling exceptions just means that now you can't catch it and it will be an automatic crash if it reaches main): https://gcc.godbolt.org/z/1s11f99a6 as the "throw" themselves are in the stdlib's implementation files, not in the headers so it isn't "your" code and isn't affected by -fno-exceptions.
I have a pretty big C++ codebase that uses noexcept on almost everything. There are a few cases where deep in the call graph something has to have a try block, but most of the unavoidable exception semantics are around std::bad_alloc, and you’re in pretty deep at that point.
clang-tidy rarely if ever misses on noexcept violations these days.
The LOL was directed at this. You can never disable exceptions in C++. No keyword or flag exists which can do this for you (-fno-exceptions and noexcept notwithstanding).
>I have a pretty big C++ codebase that uses noexcept on almost everything.
Noexcept is not enough see nearby comment by another user for explanation.
I know how noexcept works, some of the other commenters do and some don’t seem to. It’s clearly not “enough” in the sense that error handling is almost invariably one of the trickiest bits of language design, and I don’t think anyone is arguing that C++ leads the pack on it.
My assertion is that C++ is entirely workable with few concessions to the legacy of exception design, and it seemed like less of an appeal to authority to cite first-hand experience than to point out that Google has been doing it successfully for 20 years.
Mostly it works, except for memory allocation failures. These will terminate the process. But then, the Itanium C++ ABI has some quirks that make it impossible to throw an exception (any exception) in all out-of-memory conditions, so perhaps that's okay. (Throwing an exception must allocate, and the ABI currently does not allow to throw a pre-canned std::bad_alloc on allocation failure instead.)
How's that implemented? I'm just used to embedded. Implementing sbrk etc.
Some flags i use to disable exceptions
# The default flags will be used in all build types
# The C/C++ shared flags are in DEFAULT_C_AND_CXX_FLAGS, the ones particular for C or C++ in DEFAULT_X_FLAGS
# The flags mean the following:
# * no-exceptions disable exceptions support and use C++ libs without exceptions
# * delete-dead-exceptions throw away instructions which only purpose is to throw exceptions
# * no-unwind-tables stack-walking code for backtrace generation (TODO: we might want to enable this in Debug!)
# * no-non-call-exceptions do not convert trapping instructions (SIGSEGV, etc) into exceptions
# * thumb use Thumb mode (optimized instruction set)
# * function-sections put every function in its own segment, now it can be garbage collected
# * data-sections put every variable in its own segment
# * no-strict-aliasing allow *int = *float aberrations
# * no-builtin do not use abs, strcpy, and other built-in functions
# * short-enums use a single byte for an enum if possible
SET(DEFAULT_CXX_FLAGS "-std=c++17 -fno-exceptions -fdelete-dead-exceptions -fno-unwind-tables -fno-non-call-exceptions")
-fno-exceptions should be sufficient for this, especially if you link statically. People also use `-fno-rtti` to save the extra data by dynamic_cast etc.
Not only does the Itanium C++ ABI allow for using a pre-canned std::bad_alloc (because __cxa_allocate_exception() can do whatever it wants on an allocation failure), but most of the common implementations do just that.
I meant that the interface for __cxa_allocate_exception is designed in such a way that it cannot substitute std::bad_alloc for the exception being allocated.
