Sign in to follow this  
szpaq234

access to member of a child class

Recommended Posts

How do I do that ?
[code]#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;
}
}[/code]

Share this post


Link to post
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 this post


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

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

Share this post


Link to post
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 this post


Link to post
Share on other sites
[quote name='szpak234' timestamp='1310509502' post='4834545']
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.
[/quote]


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 this post


Link to post
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 [i]different[/i]. Inheritance is a special case that says that two classes are fundamentally [i]the same[/i]. 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 this post


Link to post
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 this post


Link to post
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 [/color][/font][font="CourierNew, monospace"][size="2"][color="#000080"]int[/color] [color="#660066"]GetInt[/color][color="#666600"]() = 0;[/color][/size][/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.

Share this post


Link to post
Share on other sites

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