Question

Andrei Alexandrescu writes in Modern C++ Design:

The objects returned by typeid have
static storage, so you don’t have to
worry about lifetime issues.

Andrei continues:

The standard does not guarantee that
each invocation of, say, typeid(int)
returns a reference to the same
type_info object.

Even though the standard does not guarantee this, how is this implemented in common compilers, such as GCC and Visual Studio?

Assuming typeid does not leak (and return a new instance every call), is it one “table” per application, per translation unit, per dll/so, or something completely different?

Are there times when &typeid(T) != &typeid(T)?

I’m mainly interested in compilers for Windows, but any information for Linux and other platforms is also appreciated.

Answer 1

Are there times when &typeid(T) != &typeid(T)?

I’m mainly interested in compilers for Windows, but any information for Linux and other platforms is also appreciated.

Yes. Under windows DLL can’t have unresolved symbols, thus. If you have:

foo.h

struct foo { virtual ~foo() {} };

dll.cpp

#include "foo.h"
...
foo f;
cout << &typeid(&f) << endl

main.cpp

#include "foo.h"
...
foo f;
cout << &typeid(&f) << endl

Would give you different pointers. Because before dll was loaded typeid(foo) should exist
in both dll and primary exe

More then that, under Linux, if main executable was not compiled with -rdynamic (or –export-dynamic) then typeid would be resolved to different symbols in executable and
in shared object (which usually does not happen under ELF platforms) because of some optimizations done when linking executable — removal of unnecessary symbols.