Hi, I'm kind of comparing RTTI vs a programmed type sytem of the type:

enum Type { blah, etc }

class Base
{
virtual Type GetType() const = 0;
}

For this type of system I would have to make a virtual function call,
in this regard I reckon RTTI will perform the same, or perhaps even
better. The problem is that the typeinfo object needs to be
constructed and returned, and it seems way more costly than a simple
enum.

My question really is, why was typeinfo designed like this? Wouldn't
it be better if typeinfo just was some typedef for a int, which should
be more than enough to uniquely represent all the possible classes in
even the largest system. If the user wants a string representation,
then surely that could've been accomplished with a function call using
the unique id. The only problem I see with this approach is when
linking with different libraries, but wouldn't the linker be able to
patch this up then anyway? Even as it is now typeinfo holds no
guarantee of being unique across compilers / platforms etc. Or have
some form of weak_typeid() operator with less guarantees. RTTI
could've been a perfect fit for me, in my use case I don't mind paying
for the slight memory overhead, I'm having a hard time justifying its
use due to the performance implications of the construction /
deconstruction of typeinfo.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On 2008-08-01 00:31, Sebastian Karlsson wrote:
> Hi, I'm kind of comparing RTTI vs a programmed type sytem of the type:
>
> enum Type { blah, etc }
>
> class Base
> {
> virtual Type GetType() const = 0;
> }
>
> For this type of system I would have to make a virtual function call,
> in this regard I reckon RTTI will perform the same, or perhaps even
> better. The problem is that the typeinfo object needs to be
> constructed and returned, and it seems way more costly than a simple
> enum.

It was some time I looked at RTTI, but I suspect that a type_info object
for every used type (or for which it will be needed if the compiler can
figure that out) could be created at startup and all typeid would have
to do is to return that object.

--
Erik Wikström


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Sebastian Karlsson ha scritto:
> Hi, I'm kind of comparing RTTI vs a programmed type sytem of the type:
>
> enum Type { blah, etc }
>
> class Base
> {
> virtual Type GetType() const = 0;
> }
>
> For this type of system I would have to make a virtual function call,
> in this regard I reckon RTTI will perform the same, or perhaps even
> better. The problem is that the typeinfo object needs to be
> constructed and returned, and it seems way more costly than a simple
> enum.

I understand one term of the comparison, but not the other. Could you
please post some code (or pseudocode) showing the "other" approach using
RTTI that you are considering? You know, there are many ways to use RTTI
and if you want to get a proper answer it's essential that you are clear
about which is the approach you are talking about. Moreover, it might
also help to know the use case you are facing...

Ganesh

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

In article
<41e77b2b-83a6-4f69-8c85-50ab59855fd2@w7g2000hsa.googlegroups.com>,
Sebastian Karlsson <Sebastian.Karlsson@mmorpgs.org> wrote:
> I'm kind of comparing RTTI vs a programmed type sytem of the type:
>
> enum Type { blah, etc }
>
> class Base
> {
> virtual Type GetType() const = 0;
> }

If speed is most important, you could even store the type as a field in
the object, making GetType() a single inline memory fetch and nothing
more:

class Base {
Type const type;
public:
Base( Type t ) : type( t ) { }
Type GetType() const { return type; }
};

If you're comparing to something like

class Base2 {
public:
virtual ~Base2() { }
std::type_info const& GetType() const { return typeid (*this); }
};

On most compilers I'd expect two memory fetches to get the type: one to
read the vtable pointer, and another to get the pointer to the type_info
object. A smart compiler could perhaps store the type_info object in the
vtable, perhaps at a negative offset, eliminating one of the memory
fetches.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On 1 août, 00:31, Sebastian Karlsson <Sebastian.Karls...@mmorpgs.org>
wrote:
> The problem is that the typeinfo object needs to be
> constructed and returned, and it seems way more costly than a simple
> enum.

That's incorrect.
std::type_info is never constructed at runtime. typeid() only returns
a reference to a std::type_info that is in static memory.

Moreover, RTTI has tables to allow hierarchical type identification.
(If you have a class hierarchy A : B : C, and you have an A object
accessed through a pointer/reference to C, you can identify that your
object is actually a valid B)


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

> That's incorrect.
> std::type_info is never constructed at runtime. typeid() only returns
> a reference to a std::type_info that is in static memory.


Thanks, this is what I missed. I'll go for RTTI then.

My use of RTTI would mostly be of the type:

if( typeid( component ) == typeid( PhysicsActor ) ) // Component is
PhysicsActor, safe to up cast.

And some sparse use of dynamic_cast where appropriate. The games
development community have a very strong dislike for RTTI, which going
by this information seems pretty unfounded. For above usage it should
practically perform very much like a hand crafted RTTI system if I'm
not mistaken.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Sebastian Karlsson wrote:
>
> My use of RTTI would mostly be of the type:
>
> if( typeid( component ) == typeid( PhysicsActor ) ) // Component is
> PhysicsActor, safe to up cast.
>
> And some sparse use of dynamic_cast where appropriate.

Note that if component is an object of a type publicly derived from
PhysicsActor, it still "is-a" PhysicsActor, and dynamic_cast will
succeed, but the above typeid equality test will not. This is why
dynamic_cast is usually preferred to a typeid equality test.

--
Seungbeom Kim

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On 2 août, 18:58, Sebastian Karlsson <Sebastian.Karls...@mmorpgs.org>
wrote:
> The games
> development community have a very strong dislike for RTTI, which going
> by this information seems pretty unfounded.

>From my personal experience, C++ code within the game development
community is fairly ugly, hacky and C-ish.
That aside, there are real issues with RTTI:
- It takes up some memory, as the lookup tables need to be stored
somewhere. Current compilers are still unable to remove unused extern
global variables, due to the separate compilation system.
- typeid(SomeType) is not a compile-time constant, preventing
constant-time visitation [1], which is possible with ints. Visitation
has to be done through virtual functions, which are intrusive and
cannot be templates. That is mainly due to the fact that the type
identifier is an address in static memory, which is not resolved
before link-time.

[1] A possible way would be to mangle the type names of the visited
possibilities at compile-time and build an automaton to identify the
result of std::type_info::name in constant time. That would still be
less efficient, of course.


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Mathias Gaunard ha scritto:
> On 2 août, 18:58, Sebastian Karlsson <Sebastian.Karls...@mmorpgs.org>
> wrote:
>> The games
>> development community have a very strong dislike for RTTI, which going
>> by this information seems pretty unfounded.
>
>>From my personal experience, C++ code within the game development
> community is fairly ugly, hacky and C-ish.

Sooo true! Sigh...

> - It takes up some memory, as the lookup tables need to be stored
> somewhere. Current compilers are still unable to remove unused extern
> global variables, due to the separate compilation system.

Actually a lot of current compilers *are* able to do that, including two
that are very used in the game development industry: VC++ and
CodeWarrior. BTW, both of them have link-time code generation, so they
are no longer pure separate compilation systems.

Anyway, RTTI tables for polymorphic types cannot be stripped from the
final executable in most cases, because the compiler is not able to
detect that they won't be needed at runtime.

Ganesh


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On 4 août, 05:21, Alberto Ganesh Barbati <AlbertoBarb...@libero.it>
wrote:

> Anyway, RTTI tables for polymorphic types cannot be stripped from the
> final executable in most cases, because the compiler is not able to
> detect that they won't be needed at runtime.> final executable in most cases, because the compiler is not able to

That's because even with link-time code generation, some symbols are
still unresolved (the ones from linked libraries and system calls).
And those symbols usually do not expose the global variables they
access. A shame.

The worst is that even with this code:

struct Foo
{
int value;

Foo(int i) : value(i) {}
virtual ~Foo() {}
};

void do_something(const int&);

int main()
{
Foo foo(42);
do_something(foo.value);
}

The RTTI information is not removed, at least with LLVM.


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]