3 ms·
I 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. M
by mort96 4y ago
I 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 4y 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 4y agoYou're right. Sorry.
- jcelerier 4y 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