typeid and inheritance

[mscava]

Here are my classes. Each of them has virtual destructor:

class Object { ... };
class Door : public Object { ... };
class ClosedDoor : public Door { ... };
class OpenedDoor : public Door { ... };

and here's a vector of those objects:

vector<Object*objList;
objList.push_back( new ClosedDoor );

Operator typeid returns class ClosedDoor. But I want to know wheter it
is a Door. Is there a way find this out?

Thanks for replies...

[Gianni Mariani]

ms****@gmail.com wrote:

Here are my classes. Each of them has virtual destructor:

class Object { ... };
class Door : public Object { ... };
class ClosedDoor : public Door { ... };
class OpenedDoor : public Door { ... };

and here's a vector of those objects:

vector<Object*objList;
objList.push_back( new ClosedDoor );

Operator typeid returns class ClosedDoor. But I want to know wheter it
is a Door. Is there a way find this out?

The best way is to have a virtual method on Object that tells you what
it is.

Second (by a long shot) is to use dynamic_cast.

[mscava]

The best way is to have a virtual method on Object that tells you what

it is.

Second (by a long shot) is to use dynamic_cast.

But still. I can create a method type_info GetTypeInfo() { return
typeid( *this); }. Call objList[0]->GetTypeInfo() and it will return
ClosedDoor. I want it to tell me that ClosedDoor is a Door...

[Rolf Magnus]

Gianni Mariani wrote:

ms****@gmail.com wrote:

>Here are my classes. Each of them has virtual destructor:

class Object { ... };
class Door : public Object { ... };
class ClosedDoor : public Door { ... };
class OpenedDoor : public Door { ... };

and here's a vector of those objects:

vector<Object*objList;
objList.push_back( new ClosedDoor );

Operator typeid returns class ClosedDoor. But I want to know wheter it
is a Door. Is there a way find this out?

The best way is to have a virtual method on Object that tells you what
it is.

Second (by a long shot) is to use dynamic_cast.

Why would adding a virtual member function and overloading it in every
subclass be better than using the language's built-in tool for the job?

[Rolf Magnus]

ms****@gmail.com wrote:

>The best way is to have a virtual method on Object that tells you what
it is.

Second (by a long shot) is to use dynamic_cast.

But still. I can create a method type_info GetTypeInfo() { return
typeid( *this); }. Call objList[0]->GetTypeInfo() and it will return
ClosedDoor. I want it to tell me that ClosedDoor is a Door...

Try the dynamic_cast, like

if (dynamic_cast<Door>(objList[0]))
std::cout << "Object is a door\n";

But generally, you should avoid needing the type information.

[mscava]

Why would adding a virtual member function and overloading it in every

subclass be better than using the language's built-in tool for the job?

Yes that's true. So there is no built in way in C++ to find out that
class ClosedDoor IS A Door?

[andrewmcdonagh]

On Dec 29, 1:07 pm, [e-mail] wrote:

Here are my classes. Each of them has virtual destructor:

class Object { ... };
class Door : public Object { ... };
class ClosedDoor : public Door { ... };
class OpenedDoor : public Door { ... };

and here's a vector of those objects:

vector<Object*objList;
objList.push_back( new ClosedDoor );

Operator typeid returns class ClosedDoor. But I want to know wheter it
is a Door. Is there a way find this out?

Thanks for replies...

There a few ways, but first a question....

Why do you need to check what the type is?

Asking an object (regardless that we can using built in or home grown
methods) what type it is, is usually a Design Flaw.

'Tell don't ask' is a better safer approach....

door.handleActionEvent(doorEvent);

instead of

if (door.isClosedDoor() )
{
door.close();
}
else
{
door.open();
}

Andrew

[mscava]

>

There a few ways, but first a question....

Why do you need to check what the type is?

Asking an object (regardless that we can using built in or home grown
methods) what type it is, is usually a Design Flaw.

'Tell don't ask' is a better safer approach....

door.handleActionEvent(doorEvent);

instead of

if (door.isClosedDoor() )
{
door.close();
}
else
{
door.open();
}

Andrew

Well the problem is a bit different than example. I'm making an RPG
game.

// Base class for all tiles
class Tile { ... };
// class for all Accesible Tiles
class Accesible : public Tile
// class for all Inaccesible Tiles
class Inaccesible : public Tile

Well and from those 2 subclasses - Acc and Inacc are derived all
classes, even the Door :)
And when generating Map I need to recognize wheter Tile is accesible or
not.

Ehm... I guess it would be OK to have member in tile bool isAccesible.
So this one is solved.

But still I sometimes it'd be useful to know the type it. You see. I
may have few Tile derivates like Grass, Flowers, Sand etc. And it'd be
useful to group them in one class for example Ground. So when I will
need to work with all the Grounds I will not have to write a lot ifs.

[Nikolaos D. Bougalis]

ms****@gmail.com wrote:

>Why would adding a virtual member function and overloading it in every
subclass be better than using the language's built-in tool for the job?

Yes that's true. So there is no built in way in C++ to find out that
class ClosedDoor IS A Door?

Yes, as was shown in a post <en*************@news.t-online.comby Rolf
Magnus, you can use dynamic_cast<against an object to perform a cast at
runtime. If the cast is successful (that is, it returns non-NULL) then it
worked. If it returns NULL, it didn't.

-n

[mscava]

Ok... Thank you very much guys for all your replies! I feel like I'm
gonna think more when I'll want to use RTTI. But I'll also try the
trick with dynamic_cast. Thanks.

[andrewmcdonagh]

On Dec 29, 2:48 pm, [e-mail] wrote:

There a few ways, but first a question....

Why do you need to check what the type is?

Asking an object (regardless that we can using built in or home grown
methods) what type it is, is usually a Design Flaw.

'Tell don't ask' is a better safer approach....

door.handleActionEvent(doorEvent);

instead of

if (door.isClosedDoor() )
{
door.close();
}
else
{
door.open();
}

AndrewWell the problem is a bit different than example. I'm making an RPG

game.

// Base class for all tiles
class Tile { ... };
// class for all Accesible Tiles
class Accesible : public Tile
// class for all Inaccesible Tiles
class Inaccesible : public Tile

Well and from those 2 subclasses - Acc and Inacc are derived all
classes, even the Door :)
And when generating Map I need to recognize wheter Tile is accesible or
not.

Ehm... I guess it would be OK to have member in tile bool isAccesible.
So this one is solved.

But still I sometimes it'd be useful to know the type it. You see. I
may have few Tile derivates like Grass, Flowers, Sand etc. And it'd be
useful to group them in one class for example Ground. So when I will
need to work with all the Grounds I will not have to write a lot ifs.

Yes, in this case isAccessable should be a boolean returning query
method on Tile.

As for the rest, it would appear that the Composite pattern* would be a
good design choice.

Tile <--------------------
| |
Wall Grass Flower Ground----

*intended to facilitate building complex (composite) objects from
simpler (component) parts by representing the part-whole hierarchies as
tree-like structures.

The first Google for 'composite pattern c++' gives....
http://www.codeproject.com/useritems/Composite.asp

So in your example, the Ground object would contain a number of other
Tile Objects, the exact type of which Ground does not need to know.
Andew

[Jim Langston]

<ms****@gmail.comwrote in message
news:11**********************@s34g2000cwa.googlegr oups.com...

Ok... Thank you very much guys for all your replies! I feel like I'm
gonna think more when I'll want to use RTTI. But I'll also try the
trick with dynamic_cast. Thanks.

I believe that dynamic_cast requires RTTI to be turned on in the compiler
(at least for MS VC++ 2003).