1

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).

Community
  • 1
  • 1
lapk
  • 3,838
  • 1
  • 23
  • 28
  • After a quick glance at the code it looks like you are trying to "re-implement" virtual functions. Or am I missing something? – elmo Jan 03 '12 at 11:38
  • @elmo Well, CRTP allows to implement sort of "compiler-time resolved virtual mechanism". I was answering question related to virtual functions, indeed. Specifically, implementing calls to all functions in intermediate classes in base-derived00-derived01...-derivedLast chain without specifying actual function call in any of these classes (see the original question, if interested)... But that's not the question here, it's just the framework. I'm wondering about `typeid` behavior. – lapk Jan 03 '12 at 11:47
  • does [this](http://codepad.org/OlSwkfHc) solve your problem? In general I would consider using typeid only for printing for debugging. – elmo Jan 03 '12 at 13:13
  • @elmo It's a very elegant solution to the original problem. I suggest you post it there (see link in my question post). Also, if you would combine this code + comment about names resolution into an answer, I would accept it. MSalters's answer is only pointing to the direction, since, there is no actual constructor(s) resolution evolved (notice `typename` keyword in my `typeid`'s). – lapk Jan 04 '12 at 00:09
  • posted as answers here and there. Please let me know if you see anything missing in them. – elmo Jan 04 '12 at 09:57

2 Answers2

1

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.

MSalters
  • 173,980
  • 10
  • 155
  • 350
  • Ok, if in `main` I add `std::cout << ( typeid( TDerived04 ) == typeid( TDerived04::TDerived04::TDerived04::TDerived04 ) ) << std::endl;` (it compiles under GCC, but not under MSVC++, MSVC++ wants arguments for constructor), the printed value is `true`. So, MSVC++ is trying to treat it, indeed as you said, as constructor(s). But then, why GCC prints `true`? It compares type `TDerived04` with... I'm not sure what, but it seems it treats `TDerived04::TDerived04::TDerived04::TDerived04` as type `TDerived04`. No? – lapk Jan 03 '12 at 12:31
  • Wow, GCC allows to define ` TDerived04::TDerived04::TDerived04::TDerived04 lD4;` variable. And the type is simply `TDerived04`. Is there a rule for collapsing scope resolution? MSVC++ seems to be doing the same in `typeid`, but can't handle other scenarios. – lapk Jan 03 '12 at 12:40
  • I guess this might be explained 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. Which is valid (though I am not sure that is the proper explanation). – elmo Jan 03 '12 at 13:17
  • 1
    @elmo: That's indeed what "injected class name" means. – MSalters Jan 03 '12 at 13:56
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").

elmo
  • 1,189
  • 1
  • 10
  • 35