You''re talking about virtual functions.
Make the function you want to call virtual in the character class.
Then override it in the derived classes.
Then you don''t have to cast, the compiler will route it to the derived class''s correct function.
Inheritance and Pointers...
Hey mentat,
the only reason I think its better than rtti is because I noticed that rtti is a "compiler option" in VC++. This scared me a little because after that, it appeared that it may not be possibly supported on other compilers.. Also I was worried that it would make code more bloated, such as enabling "exception handling" (being another compiler option).!
Would anyone know if GCC supports RTTI?
I am 100% for RTTI, but I use my approach because:
a) I don''t know exactly how to use RTTI.
b) I am not sure its available on other (cheaper) compilers.
I admit that my approach does have a little overhead (function call, and IF statement), but I imagine you can just make the type variable public...
www.cppnow.com
the only reason I think its better than rtti is because I noticed that rtti is a "compiler option" in VC++. This scared me a little because after that, it appeared that it may not be possibly supported on other compilers.. Also I was worried that it would make code more bloated, such as enabling "exception handling" (being another compiler option).!
Would anyone know if GCC supports RTTI?
I am 100% for RTTI, but I use my approach because:
a) I don''t know exactly how to use RTTI.
b) I am not sure its available on other (cheaper) compilers.
I admit that my approach does have a little overhead (function call, and IF statement), but I imagine you can just make the type variable public...
www.cppnow.com
Use inheritance and virtual functions, that''s what they are for... what are you guys doing??
struct basePlayer_S
{
public:
float x,y,z; //position
float dx, dy, dz; //direction
public:
virtual void Draw(void) {};
};
struct Player_S : public basePlayer_S
{
void Draw(void)
{
//Draw player here
}
}
struct Monster_S : public basePlayer_S
{
void Draw(void)
{
//Draw monster here
}
}
Now, you can simply make a list of pointers to basePlayer_S, and fill that in with Monster_S, and Player_S''s, and just call ->Draw... and it will automagically call the CORRECT draw function, isntead of doing all checks for which type, etc, etc. Unless you have functions specific to each type, it is unnecessary, and if you do have functions specific to each type, you may want to ask yourself why you''re trying to treat them as the same entity type.
struct basePlayer_S
{
public:
float x,y,z; //position
float dx, dy, dz; //direction
public:
virtual void Draw(void) {};
};
struct Player_S : public basePlayer_S
{
void Draw(void)
{
//Draw player here
}
}
struct Monster_S : public basePlayer_S
{
void Draw(void)
{
//Draw monster here
}
}
Now, you can simply make a list of pointers to basePlayer_S, and fill that in with Monster_S, and Player_S''s, and just call ->Draw... and it will automagically call the CORRECT draw function, isntead of doing all checks for which type, etc, etc. Unless you have functions specific to each type, it is unnecessary, and if you do have functions specific to each type, you may want to ask yourself why you''re trying to treat them as the same entity type.
Ready4dis, you totally missed the point. Elweren was referring to methods specific to the individual child classes and not inherited in any way from the parent class.
peace and (trance) out
Mage
peace and (trance) out
Mage
RTTI is defined by the C++ standard.
Any compiler worth it''s salt will support it. Yes, that includes GCC.
Any compiler worth it''s salt will support it. Yes, that includes GCC.
quote:Original post by Mage2kWhich is a bad idea... Klaxons should be sounding and loud speakers blaring "bad design bad design"
Ready4dis, you totally missed the point. Elweren was referring to methods specific to the individual child classes and not inherited in any way from the parent class.
RTTI is there because they realized people are going to be doing what you want to do, and they might as well give you a somewhat safe interface for doing it...
...which doesn''t mean its RIGHT
quote:Original post by C-Junkie
Which is a bad idea... Klaxons should be sounding and loud speakers blaring "bad design bad design"
So basically, what you''re saying is that any object implementing more than one public interface is bad design?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement