How does compiler evaluate `typeid` operator?

Question

Here is some CRTP based template code that I used to try and resolve this question: Requiring overridden virtual functions to call base implementations. I would post code here, but the lines are long and easier to read on codepad.org (if needed I'll post here). It's ugly and it's somewhat artificial, of course, although it does work. But what I didn't realize at first, that while it compiles on both MSVC++ and GCC, some template types are not really defined. The part I'm questioning is several long inner if( typeid( Derived(N) ) != typeid( Derived(N-1)) (symbolic notation) in TBase::OnEvent function on top.

You cannot typdef these types, it will be a compilation error - there is simply not enough derived classes for type to be defined with such long ...::TDerived::... chain, so you'll get, correctly, compilation error TDerived is not defined in TBase. Yet compiler eats them through typeid. When I checked in debugger MSVC++ compiler output (with full symbolic info), it seems that all those long ...::TDerived::... that should not really result in any class, in typeid resolved by compiler to simply the last TDerived04 in class chain. And RTTI is pulled for this last class in the class chain, independently of how many ...::TDerived::... I have.

Taking into account that both MSVC++ and GCC do that (although I only have access to GCC through codepad.org), my question is next: is it somehow defined behavior of typeid? Why then typedef of any of those long ...::TDerived::... does not resolve to TDerived04?

EDIT: I mean, I'm happy typedef does not resolve to TDerived04, that'd be disaster for anyone who uses typedef, but why such inconsistency between typeid and typedef?

EDIT: GCC accepts TDerived04::TDerived04::TDerived04::TDerived04 lD4; variable declaration. And the type is simply TDerived04 in the end. Is there a rule for collapsing scope resolution? Apparently, both MSVC++ and GCC seems to be doing the same in typeid, but MSVC++, unlike GCC, can't handle other scenarios - it gives compile error, requiring arguments for constructor(s).

Answer 1

I wouldn't consider using typeid as anything else than a tool for debugging. C++ standard only guarantees its existance, but doesn't really say what it should do. This renders this utitlity as nothing more than a way to print a human readable class names (please correct me if you know any other practical use).

I would say there is too much "compiler defined" behaviour of typeid to make it useful for anything else than above.

Approach presented in the solution also has a huge drawback. Besides being ugly and hard to maintain, the base class requires to know about all derived classes. This is quite a big design flaw.

As for alternative solution it can be seen here (code also posted in original question).

As for TDerived04::TDerived04::TDerived04::TDerived04 being valid is can be exaplained by that in TDerived04 class you can refer to this class/namespace using its name TDerived04. So TDerived04::TDerived04 is like pointing at class TDerived04 from TDerived04 (as @MSalters said it is called "class name injection").

Answer 2

The problem roughly is that there is an ambiguity between the injected class name and the constructor name. In the scope of class X, X can name the class itself, but X::X can also refer to the constructor - where that makes sense.