My question pertains specifically to the Windows compiler (v19 Update 3) running in VS2017 v15.9.9.
I have a class in a third-party lib that is compiled with no RTTI (/GR-). This library defines several C++ types.
My project subclasses one of these library types. The compilation (.cpp) unit that contains this subclassed type is also compiled with /GR-. In the client's calling function (which resides in a compilation (.cpp) unit compiled WITH RTTI enabled), I am finding that typeinfo is being injected anyway into instances of these "non-RTTI" types, such that statements like dynamic_cast<> and typeid(…) succeed. This behavior is inconsistent with what I observe under Linux and GCC which emits the expected:
"undefined reference to 'typeinfo' for 'ident'"
I do not believe the compiler should be silently "elevating" these non-RTTI types to RTTI types as it allows parts of the language to be used which are otherwise (and should be) unsafe. The only way I can achieve conformance with types compiled with /GR- is to ban RTTI for ALL compilation units in the project. This seems unnecessarily restrictive to clients.
Is this behavior known? Expected?
- Development Tools
- Intel® C++ Compiler
- Intel® Parallel Studio XE
- Intel® System Studio
- Parallel Computing
Viet Hoang (Intel) wrote:
Will you see the same problem if you compile with cl?
Yes, I do see the same behavior with cl. Clang and GCC seem to enforce the restriction with -fno-rtti. I don't know what the behavior of the Intel compiler under Linux is.
Intel compiler is compatible with GCC on Linux and is compatible with Microsoft on Windows. That fact that you see the same behavior with cl, then it's likely not icl issue.