6 ms·

You can usually compile each library independently with/without exceptions and rtti and it works as expected.

• mhh__ 3y ago
  Works as expected or silently fails to destruct things properly during unwinding?
  • mort96 3y ago
    Haven't tried, but it almost certainly fails in fun and unexpected ways I'd guess. Code which happens to be in your dependencies' source files probably works as expected, code which happens to be in your dependencies' source files will be compiled without RTTI/exceptions and therefore possibly break in fun and interesting ways. And I wonder what happens if your code creates a class which inherits from a base class defined in a library and that library expects anything which inherits from that base class to have runtime type info.
    • Kranar 3y ago
      Nothing breaks in fun or interesting ways. All that happens is std::terminate is called.
      • mort96 3y ago
        Even when a template or inline function depends on RTTI but is called in a source file compiled with -fno-rtti? And if a template or inline function depends on catching an exception, you're right that your app unexpectedly crashing due to std::terminate isn't "fun or interesting" but it's not really great either.
        • Kranar 3y ago
          Templates and RTTI do not have anything to do with each other. An inline function that depends on RTTI will fail to compile when -fno-rtti is enabled. There is also nothing unexpected about an application immediately terminating due to an exception. That's the most expected outcome in an application that has made an explicit choice to not handle exceptions and is what happens in any application that does not have a try/catch handler.
          • mort96 3y ago
            Templates and inline functions are relevant because they're in headers and therefore compiled as part of your project's translation units. So if a function from a library depends on RTTI, and it's compiled as part of your project's translation units with -fno-rtti, something will break (or maybe you'll have an ODR violation). > There is also nothing unexpected about an application immediately terminating due to an exception. That's the most expected outcome in an application that has made an explicit choice to not handle exceptions and is what happens in any application that does not have a try/catch handler. If I call a function from a library, and that library function depends on catching and handling exceptions (maybe it uses a stdlib function which throws, such as vector::at), it's unexpected that my application crashes due to that exception. Yet, if that library function happens to be in a header, calling it will crash my program (or, again, you have an ODR violation and anything could happen).
            • Kranar 3y ago
              You get a compiler error.
              • mort96 3y ago
                Seems like it's an error on GCC and Clang, though just a warning on MSVC. That makes it much less of a foot gun at least.
            • Kranar 3y ago
              >If I call a function from a library, and that library function depends on catching and handling exceptions This doesn't make any sense. If a function from a library depends on catching and handling an exception then it can continue to do so. Using -fno-rtti doesn't change the semantics of functions that were compiled without that flag, they can continue working as usual. All -fno-rtti does is treat your program as if any exception thrown goes unhandled, which in C++ means that std::terminate is called. If you're saying you have a function that throws an exception and that function expects someone else to catch it, then the problem isn't with -fno-rtti, the problem is with your function's expectations. That means your function is using exceptions as a form of control flow, which is not a recommended practice. The primary goal and intention of exceptions is that the function that throws it is agnostic about how the exception is handled, or whether the exception is handled at all. A function fails to meet its post-condition can throw an exception. If that exception gets caught then the receiver of that exception makes the decision on to proceed (not the thrower), if that exception does not get caught then std::terminate is called. All -fno-rtti does is guarantee that any exception thrown goes uncaught. This is the least surprising behavior one can expect. What possible alternative behavior would you want from a function that throws an exception that goes uncaught?
  • Calavar 3y ago
    It's similar to slapping noexcept on every function in a compilation unit. Unwinding will still happen as usual in compilation units where exceptions were enabled. When a function in an -fno-exceptions compilation unit calls a function that might throw exceptions, the compiler inserts an exception handler that calls std::terminate. std::terminate won't call any destructors further up the chain, but if all you're doing in destructors is deallocating memory and releasing handles to system resources, this shouldn't matter.
    • inetknght 3y ago
      > if all you're doing in destructors is deallocating memory and releasing handles to system resources, this shouldn't matter. Note that closing system resources is often abortive. On the other hand, object destructors might wait for a flush.
    • wyldfire 3y ago
      > if all you're doing in destructors is deallocating memory and releasing handles to system resources, this shouldn't matter. That "if" is doing some heavy lifting. C++ places a lot of stock in RAII, so failing to call destructors could cause lots of interesting failure modes. I don't think it's fair to dismiss this fundamental part of the language so easily.
      • Calavar 3y ago
        If the user kills your program with Ctrl-C, you don't have any destructor guarantees. If your program is killed by the OS because the user logged off or powered down their machine, you don't have any destructor guarantees. If your program fails an assertion, you don't have any destructor guarantees. If your program segfaults, you don't have any destructor guarantees. This really isn't that exotic of a scenario. My personal opinion is that using RAII to do anything that you wouldn't trust the OS do for you in the event of an early termination is setting yourself up for disaster.
        • hamilyon2 3y ago
          Do you have a newsletter that I can sign up for?
  • jcelerier 3y ago
    -fno-exceptions does not disable unwinding support afaik, for this you need -fno-unwind-tables / -fno-asynchronous-unwind-tables ; if I'm not mistaken unwind table generation is enabled even in C with GCC and clang
• pjmlp 3y ago
  It works by chance more than anything.