5 ms·

Nothing breaks in fun or interesting ways. All that happens is std::terminate is called.

by Kranar 3y ago

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?
      - mort96 3y ago
        You seem to be completely misunderstanding what I'm saying. Of course a function compiled without -fno-rtti or -fno-exceptions can keep using those features. There's a reason I keep talking about functions defined in headers. Those functions are compiled in your program's translation units, with your program's compiler options.

Nothing breaks in fun or interesting ways. All that happens is std::terminate is called.

by Kranar 3y ago

Nothing breaks in fun or interesting ways. All that happens is std::terminate is called.

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?
    - mort96 3y ago
      You seem to be completely misunderstanding what I'm saying. Of course a function compiled without -fno-rtti or -fno-exceptions can keep using those features. There's a reason I keep talking about functions defined in headers. Those functions are compiled in your program's translation units, with your program's compiler options.