views:

482

answers:

2

Hello

I am using Visual Studio 2005 Proffesional Edition.

In the following example SomeClass is class that is defined in third party dll library I am using. SomeClass has virtual methods. I noticed that the operator typeid gives different results when applied to the type itself, and when applied to object of the type. Is this normal behavior, and if not what could be the reason for such behavior?

typeid(SomeClass).raw_name()   // the value of this is   ".?AVSomeClass@@"
typeid(SomeClass).name()          ///  "class SomeClass"

SomeClass obj;
typeid(obj).raw_name(); // ".?AVTLomeClass@@"
typeid(obj).name();       // "class TLomeClass"
+1  A: 

The reason for this behavior is documented somewhere on MSDN. The specific behavior you're seeing in this particular case is probably due to some use of inheritance, or some compiler extension, not documented by the .DLL's vendor.

The operator's behavior is not defined by the C++ standard, and as such is a compiler extension. You can not rely on its behavior, nor can you have any reasonable expectation of finding out why it does what it does in the way that it does, unless it's explicitly documented by the vendor. Its behavior may have changed in VS2008, and likely differs from VS2003. (It certainly differs from GCC, ICC, and various other compilers.)

greyfade
Thank you for your reply.This help me a lot. Actually, after some investigation, I came to conclusion that the vendor has some undocumented futures of the particular class.
I'm sorry: what?!!! Operator `typeid` is clearly and explicitly defined by C++ standard. It is not a compiler extension.
AndreyT
Yes, typeid is 8defined* in the standard, but its *behavior* is not. The only explicit requirement is that: `typename A a1, a2; assert(typeof(a1) == typeof(a2));` Anything beyond that, by my reading, is an extension.
greyfade
No, the behavior of `typeid` is perfectly defined, at least for the purposes it is intended to be used for. There's nothing undefined in type-identification properties of `typeid`. In case of `A a;` the standard guarantees that `typeid(A) == typeid(a)`. What is really undefined, is the format of the "names" returned by the above methods, but that's not the issue in this case.
AndreyT
A: 

Is the code in your question the same or similar to the code you are having problems with?

Operator typeid, when it is applied to polymorphic types, returns the type_info object that identifies the dynamic type of the polymorphic object. So, for example, if you apply typeid to a reference of type Base & (where Base is polymorphic), which is actually bound to an object of type Derived (where Derived is derived from Base), the type_info object returned by typeid will correspond to the Derived class, not to Base class. Could it be that something like that is happening in your code?

Also, in some compilers (like MS Visual Studio) in order to use fully-functional typeid, as described above, you need to compile your code with Run-Time Type Information (RTTI) enabled. Maybe the absence of RTTI led to the strange effects you observed.

P.S. Contrary to what is stated in the currently accepted answer, typeid is fully and perfectly standard C++ feature. It is not a compiler extension.

AndreyT
Yes, you are right. In my example I was having a library function that returns base pointer which points to derived class object. However, the signature of the function was Base* function(), and in the library documentation Base class apperead as leaf class i.e no classes were specified to inherit from it. But I guess so, that the function actually was returning a pointer which points to more derived class which is not sayed in the libary documentation. I.e if I say this :Base baseObj;Base* basePtr=fucntion();then the following statement is truetypeof(baseObj)!=typeof(*basePtr)