Each template instantiation of ChildClass will have another ID. So, for example, ChildClass<MyClass> will have another ID as ChildClass<MyOtherClass>. Using the same template parameter(s) will result in the same ID.

Note: Although I've tested this only with Visual C++ 2010, it seems logical that this will work with other compilers too. I haven't tested this across DLL boundaries.

Comments and Discussions

1.You are right about virtual methods. Nobody is sure how the dynamic_cast is implemented, but some people hint that it is possible than the first entry in the vtable in some compilers is a pointer to the type info, that was set at compile time, and the dynamic_cast just uses the same vtables as virtual methods do

2. The example does not should be complete, but IMHO should show essentials. People wit very different levels of C++ skills will read it.
By a way, is the Child derived from Base?
3. Because the comparison is not shown, this post is about comparison of the template parameters only. So static_cast is not related to this post. After you have determined the template parameters are the same, you are free do what you want. I would remove the cast.
4.Your method of generating ID leads to different IDs for the same template parameter, because the OS might allocate different memory pages for the different instances of the app. Of course, they are constant inside the given app instance.
5. You are saying that your code is the fastest. Did you have any numbers?

1. You do not want to use run time type info (dynamic_cast), but you are actually using RTTI because you are using virtual functions. The call to the virtual function is resolved at run time: the app determines the dynamic type of the pointer to the base class and looks into the virtual functions table of the basic class. As you remember, if you have BaseClass* bPtr = new ChildClass, the bPtr has a static type BaseClass* and dynamic type ChildClass*.
2. The code you wrote has bugs: no virtual destructors, bool equal() never returns true, the child class has no ancestor.
3. If your intention is to compare types, why do you do a static_cast? Return true if ids are the same, and that's it.
4. In ClassID() you wrote:
static int id;
return (int)&id;
On 64bit system the address is 64 bit. If you truncate it, you can't guarantee uniqueness.

In my opinion, using the ID to compare class types is legit, but your implementation is deeply flawed.

1. RTTI has nothing to do with virtual methods.
2. It's just an example that's not meant to be complete. It's stripped down to show the essential code.
3. "equals()" compares whether two instances (not types) are the same. The comparison isn't shown in the example (as it depends on the class' implementation - again, it's just an example). However, if the types are different, the instances can't be the same.
4. That's a good point.

I should have written that this is supposed to be a very fast method of comparing types in cases where you have complete control over the implementation of all classes that are inheriting from BaseClass (like with private classes). Of course you can completely break this thing by not correctly overloading "classId()" but again, this method was meant to be fast and not to be dummy-safe.

As the tip is currently written, the ChildClass::equals method would be generating at least a warning because of incomplete code paths. Also the static_cast following the comparison is not used or leading anywhere.

I think code samples (even if it is only a tip) should be somewhat consistent.

You're reinventing typeid typeof and the rest, but worst, you're making all the common error of a naive implementation. If you either derive from a ChildClass, you might get the same classID (because you might forget to overload the method).
There is no persistance either in the id (meaning that from one run of the software to another run you'll get different results), and you can't map back to the class name to figure out the id.
You're also paying the cost of adding/growing a virtual table, while typeid doesn't (since it's compile-time based indentification).

I do not think it is safe and good. All code is based on assumption that somebody have assigned right IDs to both classes. What if the IDs are the same, but the child class is bigger than other (e.g has more data members)? You can't cast up the inheritance ladder, only down.
Because you are not using inheritance, the only sense it makes is to cast between instantiations for the different T of the same class template.
This is a case for using TypeLists and static_asserts.
Set the TypeList for types that allow casts. and overload the cast operator
like
template childClass operator ()(const childClass)
and in body of that operator trow static_assert if the T1 is can't be casted to T