4 ms·
>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 l
by 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 agoYou 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.
- Kranar 3y agoAnd you seem to completely misunderstand how -fno-rtti works but you speak as if you're knowledgeable about it despite the fact that it's absolutely obvious you've never even bothered to try it yourself or read the documentation for it. It's very hard to understand someone who is repeatedly making false claims but doesn't realize it. If you don't know how something works, please avoid making claims about it as if you did know such as: >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). That's a false claim and saying it does nothing but create confusion and spread misinformation. Especially since you're referencing ODR violations which to someone who doesn't know better might be fooled into thinking your claim is more credible than it really is (there is no ODR violation).
- mort96 3y agoI didn't know that certain compilers (though not all) will error in that situation. I'm sorry. You will only have fun unexpected behaviors on some compilers. Maybe we could've gotten to this point faster though if you didn't keep responding as if I wasn't talking about library functions defined in headers.
- Kranar 3y agoMy second reply to you was: >An inline function that depends on RTTI will fail to compile when -fno-rtti is enabled. Note that you completely ignored that point. >You will only have fun unexpected behaviors on some compilers. I made it very clear, as did OP, that we were discussing the use of -fno-rtti. There is not a single compiler where that flag does not behave the way as I described. You are discussing MSVC which does not have an -fno-rtti but instead uses a /GR- which behaves differently from -fno-rtti. When discussing detailed matters involving C++ compilers and toolchains, precision matters. Especially since clang has a compatibility mode with MSVC where it too implements both /GR- and -fno-rtti and treats them as separate flags with different behaviors.
- mort96 3y agoYou're right. Sorry.
- jcelerier 3y agoThat's assuming you don't include a header that will somewhere have some #if defined(__cpp_rtti) Some ABI- or ODR- breaking code #endif Given how much of these ifdef I can find by grepping on the repos I have cloned on my hard drive, I would in practice really not be too confident about mixing -fno-rtti with -frtti code