When can typeid return different type_info instances for same type?

Question

Andrei Alexandrescu writes in Modern C++ Design:

The objects returned by typeid have static storage, so you don\'t have to worry abou

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.