Sign in to follow this  

Non Standard RTTI Compiler behaviour.

This topic is 4304 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I have a little question for people who have more compilers installed than i do. The ANSI C++ standard requires that a compiler has to generate code so that on a call to typeid( x ) a valid std::type_info instance is guranteed to be returned for classes that have a VTABLE ( meaning at least one virtual function ) and not for each other type. However i am in need of RTIT type information for EVERY type. The VisualC Compiler implements this NON STANDARD behaviour. ( every version since 6.0 ) returning RTTI even for PODs ( int,float etc. ) I would like to hear if common other compilers support that kind of behaviour too. (e.g GCC;COdeWarrior etc. ) SideNOTE: Yes i know RTTI is not a good idea in general, but my use of it is varanted by the special task at hand ( developing a full scale type reflection system for Native C++ ).

Share this post


Link to post
Share on other sites
Erm, I was under the impression that typeid was guaranteed to return info in most instances. The vtable-only related stuff you're refering to is probably related to a situation like this:

Base * foo = new Derived;
std::cout << typeid( *foo ).name() << std::endl;


If Base has a vtable, then the above will return the same as typeid(Derived).name().
If Base does not have a vtable, then the above will return the same as typeid(Base).name() *.

* Note: this might be isn't implementation specific behavior, but it's the most common that I've seen (thanks for the standard-confirmation bellow, Conner McCloud!). This includes Visual Studio:

#include <iostream> //for cout
#include <memory> //for auto_ptr
using namespace std;

struct Base {};
struct Derived : Base {};

struct VBase { virtual ~VBase() {} };
struct VDerived : VBase {};

int main () {
auto_ptr< Base > p_to_non_virtual( new Derived );
auto_ptr< VBase > p_to_virtual( new VDerived );

cout << typeid( *p_to_non_virtual ).name() << endl;
cout << typeid( *p_to_virtual ).name() << endl;
}




The above results in, on VS2k5 Express:

class Base
class VDerived


Even though the types in question are really Derived and VDerived. I can't recall seeing wildly different behavior than this, ever - some other compiler results:

G++ 3.3 and 4.0.0 on OS X, MinGW port of G++ 3.4.2 on Windows XP Home
4Base
8VDerived


[Edited by - MaulingMonkey on March 5, 2006 9:13:17 PM]

Share this post


Link to post
Share on other sites
Thanks for your reply.

As far as i know from the standard it is really as I said, however i also have to handle the special case you pointed out so the problem still persists.
Damn have to buy my copy of the standard very soon.

And i have tested all Visual C compilers i have handy ( VC6,7,7.1,2005 ) i only have doubts about the functionalty for GCC and others.

Also interesting would be what a
int a = 0;
typeid(a) prints ...

Share this post


Link to post
Share on other sites
Quote:
5.2.8.3
When typeid is applied to an expression other than an lvalue of a polymorphic class type, the result refers to a type_info object representing the static type of the expression. Lvalue-to-rvalue (4.1), array-to-pointer (4.2), and function-to-pointer (4.3) conversions are not applied to the expression. If the type of the expression is a class type, the class shall be completely-defined. The expression is not evaluated.

Share this post


Link to post
Share on other sites
Quote:

Also interesting would be what a
int a = 0;
typeid(a) prints ...


That doesn't use RTTI. It uses static type information.

If pretty certain that RTTI is only supported for polymorphic types on the compilers you mentioned. To test it try this:


int a = 0;
float* f = reinterpret_Cast<float*>(&a);

typeid(*f);//should print float, because there is no RTTI - just the static info.


Share this post


Link to post
Share on other sites
Thank you very much, that clarifies it a bit, and the results are completly satisfactory for my use ( static type information IS fine for most cases by me )

Share this post


Link to post
Share on other sites

This topic is 4304 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this