• Popular Now

• 13
• 14
• 27
• 9
• 9

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

Recommended Posts

How do I do that ?
#include <iostream> class Mother { public: Mother(){} }; class Son : public Mother{ private: int f_iA; public: Son(int _in){f_iA = _in;} int GetInt(){return f_iA;} }; Mother* pSon; int main() { pSon = new Son(5); std::cout<<pSon->GetInt(); //'GetInt' : is not a member of 'Mother' return 0; } }

Share on other sites
If you know that it's a Son object you can use a cast to turn the Mother pointer to a Son pointer. Ex: Son * son = static_cast<Son *>(mother). If you don't know for sure, you can use a dynamic_cast instead of a static_cast, which will return a null if it isn't the appropriate type. The best way, however, is not to lose that type information in the first place.

Share on other sites
I guess you meant this:
int main() { pSon = new Son(5); std::cout<<static_cast<Son*>(pSon)->GetInt(); return 0; }

That one worked. Heh, i did not get the meaning of casting. Maybe i have to go through it again. Thx anyway.

Share on other sites
There is much wisdom in SiCrane's final line. Restating your design can often avoid such casts, which are brittle and ugly.

Share on other sites
Can you give me some pointers ? My idea was to make all objects in my applications derived from one class. I can't use virtual functions because then i will have override them in all derived classes.

Share on other sites

Can you give me some pointers ? My idea was to make all objects in my applications derived from one class. I can't use virtual functions because then i will have override them in all derived classes.

That might end up being a bad idea. I would favour composition over inheiritance. If something has visuals it can have a visual object (rather than inheriting from soem visual object). If something has position/orientation information then it should have it, rather than inheirit from soemthing which has it. Both ways work so it is up to you but having tried both I find the best way is composition (check out component based entities - everything is just one type "entity" but can have substantially different behaviour).

You don't "have" to override virtual functions if you don't want to. If you find you always have to otherwise they don't make sense, then that might suggest against using inheritance to begin with.

Share on other sites
Why on earth would you want everything to derive from a single class?

The idea of classes is that every class represents something that is different. Inheritance is a special case that says that two classes are fundamentally the same. If you have lots of things which are different (classes) all pretending to be the same (shared base class for everything) then you get really, really bad code.

Share on other sites
To what end? What will deriving all your classes from some arbitrary base buy you?

In C++, this generally isn't necessary or desired. Inheritence is rare, it is one of the strongest forms of coupling - think twice, don't just use it out of convention.

If you describe your game or application we will be better placed to give you hints and tips for a core design that doesn't do this.

Share on other sites
The above posts are correct that this isn't a solution you need often, but there are times when it is the best design.

There are legitimate designs (including several in the standard library) where the base functionality needs to get information or processed results from a derived class.

In that case you simply create it as a virtual function in your base class:

[font="Courier New"][color="#000080"]virtual [/font][font="CourierNew, monospace"][color="#000080"]int [color="#660066"]GetInt[color="#666600"]() = 0;[/font]

It is less brittle than the static cast and allows the base code to use instance-specific functionality.

For example, the stream classes use traits to allow conversions without the base class needing to knowing the details. The specialized classes do the work and give converted results to the base class. Other programmers can write their own traits and they are automatically used thanks to inheritance. You can change the behavior of the streams at runtime by imbuing the stream with a different set of traits.

An alternate form of the same thing is to require it through template specialization. This is a how iterator traits are implemented in the Standard Library. They could write the generic functionality while still allowing programmers flexibility to adjust or optimize the base behavior when used on their own classes.