> The "slowness" has to do with allowing the code to correctly compare two
> typeid(x) possibly coming from different DLLs. That could easily produce
> two different addresses, even if they are both constant.
You're right. I just wrote a little EXE and DLL that tests this.
This is the shared header:
struct S
{
virtual void f();
};
void S::f()
{
}
This is the DLL (ignore the __declspec(...)):
#include <windows.h>
#include "..\shared\shared.h"
__declspec(dllexport)
void GimmeObject( S *&pS )
{
static S s;
pS = &s;
}
This is the executable:
#include <iostream>
#include "..\shared\shared.h"
using namespace std;
__declspec(dllimport)
void GimmeObject( S *&pS );
int main()
{
S s;
S *pS;
GimmeObject( pS );
cout << "typeid(s) == typeid(*pS): "
<< (typeid(s) == typeid(*pS) ? "true" : "false")
<< endl;
}
The whole Visual Studio 2019 project can be downloaded here:
https://transfer.sh/F4QKl/typeid_dll.zip
> The language standard doesn't say anything about dynamic libraries,
> so this is an extension.
Ok, and I think this also applies to dynamic_cast; i.e. you could
downcast an object built in a DLL to a class included in an EXE.
But I think it would have been cleverer to say that this doesn't
work across DLL / excecutable boundaries and let the VMT-pointers
and RTTI-information be a part that could be imported by indidual
compiler-directives. This would allow more performant implementa-
tions; f.e. type_id::hash_code() could be simply the address of
the VMT-table.