When can typeid return different type_info instanc

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

Standards sometimes leave certain behavior unspecified in order to give implementations some freedom. In this case, how TypeIDs are managed is being left up to the compiler implementation and you're simply being given a set of rules (essentially: don't concern yourself with how memory for this is being allocated).

Is there any particular reason why you need to be able to compare TypeIds based upon their memory address? TypeIds already override == and != in order to provide you with the ability to compare them, and provide a name() that might be used to identify them uniquely.

If you've got The C++ Programming Language (Bjarne Stroustrup) available, chapter 15 has a lot of details about handling class hierarchies. Maybe you might find another solution there?

Answer 2

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.