Re: New to OOP, please Help
Either
Code:
Boy*p1;
p1 = new Boy();
p1->gotoFootball();
or
Code:
Person *p1;
p1 = new Boy();
((Boy*)p1)->gotoFootball();
Re: New to OOP, please Help
Re: New to OOP, please Help
Quote:
Originally Posted by
phuzer88
Hi All,
I am new to OOP. I am trying to do something similar like the following code (using inheritance).
Code:
class Person {
public:
Person ()
{ cout << "Person: constructor\n"; }
void talk()
{ cout << "Person: talk\n"; }
void walk()
{ cout << "Person: walk\n"; }
};
class Boy : public Person {
public:
Boy ()
{ cout << "Boy: constructor\n"; }
void gotoFootball()
{ cout << "Boy: football\n"; }
};
class Girl : public Person {
public:
Girl ()
{ cout << "Girl: constructor\n"; }
void gotoDance()
{ cout << "Girl: dance\n"; }
};
then in the main function, have the following code
Code:
Person *p1;
p1 = new Boy();
p1->gotoFootball();
this however doesn't compile as gotoFootball is not recognized by Person. Is it possible to achieve something like this please? Also I know this is a 'stupid' example but I tried to keep it simple till I understand how it works.
Thanks :)
You need to learn about polymorphism. If this tutorial doesn't answer your question, I can help explain.
Quote:
Originally Posted by
VictorN
Either
Code:
Boy*p1;
p1 = new Boy();
p1->gotoFootball();
or
Code:
Person *p1;
p1 = new Boy();
((Boy*)p1)->gotoFootball();
I can't believe you would answer that.
Re: New to OOP, please Help
Quote:
Originally Posted by
phuzer88
Hi All,
I am new to OOP. I am trying to do something similar like the following code (using inheritance).
Code:
class Person {
public:
Person ()
{ cout << "Person: constructor\n"; }
void talk()
{ cout << "Person: talk\n"; }
void walk()
{ cout << "Person: walk\n"; }
};
Your Person object is missing a virtual destructor. Therefore this code has undefined behaviour:
Code:
Person *p1;
p1 = new Boy();
p1->gotoFootball();
delete p1; // you forgot this but you are now introducing undefined behaviour.
When you are creating a class that is meant to be derived from, you must have a virtual destructor defined in the base class. If you don't do that, deriving from your base class and then creating objects using a base pointer leads to undefined behaviour when that base class pointer is deleted.
Code:
class Person
{
//...
public:
virtual ~Person() { } // you must add this
};
Regards,
Paul McKenzie
Re: New to OOP, please Help
Quote:
Originally Posted by
Paul McKenzie
Your Person object is missing a virtual destructor. Therefore this code has undefined behaviour:
Good point, Paul! :thumb:
And I'm sorry for the incorrect reply! :sick:
Re: New to OOP, please Help
Quote:
Your Person object is missing a virtual destructor. Therefore this code has undefined behaviour:
Code:
Person *p1;
p1 = new Boy();
p1->gotoFootball();
delete p1; // you forgot this but you are now introducing undefined behaviour.
Don't you mean "well-defined but incorrect behaviour", rather than "undefined behaviour"?
Won't the compiler generate a non-virtual destructor for Person which will be invoked by the delete statement? Since the destructor is not in the v-table, however, derived classes won't override it and will therefore potentially leak resources?
Re: New to OOP, please Help
Quote:
Originally Posted by GeoRanger
Don't you mean "well-defined but incorrect behaviour", rather than "undefined behaviour"?
No, that delete results in undefined behaviour. That much is explicitly stated in the C++ standard.
Re: New to OOP, please Help
The trouble with polymorphism, is you need to anticipate in the base class all the stuff you will need to do through a base class pointer, in the derived classes. iow virtual functions. You can change what happens when MyVirtual() is called through the base class pointer by deriving a class and changing what happens in the implementation of the method. What you can't do, is go back to scratch when you find out you really need MyVirtual2(). That's why you see stuff like .NET Framework 1.0 1.1 2.0 2.1 3.0 3.5 4.0 4.5 yadda yadda and also COM dll MyServer and after a bit MyServer2. Unless you polish your crystal ball you can't anticipate everything you're going to need 2 years from now in the initial design.
That's why there's an adage to do with code a prototype, get it to work. learn how the task really functions, now that you know, throw the first design away and come up with something that will actually work well.