OK!
I had this nagging doubt

Consider (without worrying abt access specifiers)
class Kid : public Parent{...};

Parent::someFunc()
{
Kid k;
}
ISSUE- this new Kid , while constructing it, can't I make the
parent of this new kid point to the already existing parent. DO we
REALLY NEED to create a Parent each time a Kid object is created.

Thanks a lot!
JON

* jon wayne:
> OK!
> I had this nagging doubt
>
> Consider (without worrying abt access specifiers)
> class Kid : public Parent{...};

This says that a Kid is always a Parent, from the moment it's born.


> Parent::someFunc()
> {
> Kid k;
> }
> ISSUE- this new Kid , while constructing it, can't I make the
> parent of this new kid point to the already existing parent. DO we
> REALLY NEED to create a Parent each time a Kid object is created.

You have said, via the inheritance, that every Kid has a Parent base class
sub-object.

But probably the inheritance is plain wrong, otherwise you wouldn't ask.

jon wayne wrote:
> OK!
> I had this nagging doubt
>
> Consider (without worrying abt access specifiers)
> class Kid : public Parent{...};
>
> Parent::someFunc()
> {
> Kid k;
> }
> ISSUE- this new Kid , while constructing it, can't I make the
> parent of this new kid point to the already existing parent.

No.

DO we
> REALLY NEED to create a Parent each time a Kid object is created.
>

Yes.

If these facts are wrong for your program, then you shouldn't be using
inheritance.

john

jon wayne wrote:
> OK!
> I had this nagging doubt
>
> Consider (without worrying abt access specifiers)
> class Kid : public Parent{...};
>
> Parent::someFunc()
> {
> Kid k;
> }
> ISSUE- this new Kid , while constructing it, can't I make the
> parent of this new kid point to the already existing parent. DO we
> REALLY NEED to create a Parent each time a Kid object is created.

I think you need a different design. Yours says that a Kid is also a Parent.
Here's a suggestion:

class Person
{
// members common to all people
};

class Kid : public Person
{
// members common to just Kids
// including possibly pointers to Parents
};

class Parent : public Person
{
// members common to just parents
std::vector<Kid> children; // (or vector<Kid*>) the parent's children
};

This still isn't right, assuming you are trying to model human families,
because _two_ parents share the same children, but you get the idea.

DW

David White wrote:
[..]
> // members common to just parents
> std::vector<Kid> children; // (or vector<Kid*>) the parent's children
> };
>
> This still isn't right, assuming you are trying to model human families,
> because _two_ parents share the same children, but you get the idea.
>
> DW
>
I felt that the OP was just using Kid and Parent as role describing
names, rather like people use Base and Derived. But yes if he *really*
has a class called Kid derived from a class called Parent, then
something is seriously wrong.

john

"jon wayne" <jon.wayne.01> wrote in message
news:5300
> OK!
> I had this nagging doubt
>
> Consider (without worrying abt access specifiers)
> class Kid : public Parent{...};
>
> Parent::someFunc()
> {
> Kid k;
> }
> ISSUE- this new Kid , while constructing it, can't I make the
> parent of this new kid point to the already existing parent. DO we
> REALLY NEED to create a Parent each time a Kid object is created.
>
> Thanks a lot!
> JON
>

I think the OP is mistaking an object-level relationship with class-level
relationship. What the OP wants to model, is the relationship between a kid
and a parent, which, naturally, is an object-level relationship. This
relationship can be built up on object reference in general, or pointers to
objects in C++:

class Person
{
public:
Person* parent1;
Person* parent2;
// ...
};

Person Merlin;
Person Amily;
Person Oliver;

// Oliver is the son of Merlin and Amily:
Oliver.parent1 = &Merlin;
Oliver.parent2 = &Amily;

The OP takes the fact that a human kid usually inherits from his/her
parent(s) and try to use C++ inheritance to model at class level, which is
the wrong anology. In C++, a derived class is-a and includes a base class.
For example, an apple is a fruit, and an apple includes everything you can
imagine in a fruit, so you can use an apple in anyway you can use a fruit.

A kid is not (necessarily) a parent. You certainly should not, and cannot,
treat your kid exactly the same way you treat your parent. A parental
relationship is down to individuals, and is an object-level relationship.

Ben

"John Harrison" <john_andronicus> wrote in message
news:3957
> David White wrote:
> > I think you need a different design. Yours says that a Kid is also a
Parent.
> > Here's a suggestion:

[snip]

> I felt that the OP was just using Kid and Parent as role describing
> names, rather like people use Base and Derived. But yes if he *really*
> has a class called Kid derived from a class called Parent, then
> something is seriously wrong.

I thought the use of the name 'Kid', rather than 'Child', along with the
implication that the parent already exists, suggested that the names were
meant to be taken literally. Anyway, the OP can clarify if necessary.

DW

"jon wayne" <jon.wayne.01> wrote in message
news:5300
> OK!
> I had this nagging doubt
>
> Consider (without worrying abt access specifiers)
> class Kid : public Parent{...};
>
> Parent::someFunc()
> {
> Kid k;
> }
> ISSUE- this new Kid , while constructing it, can't I make the
> parent of this new kid point to the already existing parent.

What do you mean by "parent of"? Using class names which are the same as
concepts (such as parent, meaning the specific class "Parent", as well as
the generic meaning "base class", sometimes also called "parent class"),
makes it difficult to determine what you're referring to.

There are two kinds of parent-child relationships (disregarding your class
names for the moment). One is inheritence, which you've shown, where some
people refer to the base class as the parent class.

There is also the "tree" relationship, where a "parent node" contains
pointers to one or more "child nodes", and a "child node" often contains a
pointer to its "parent node". If that's what you're talking about, then you
should not be using inheritence here. So I'll assume you're talking about
inheritence...

The Kid class has no "pointer" to a "parent", at least not in the code
you've shown. It is derived from Parent, and can be considered to actually
_be_ a Parent in this case (since you've used public inheritence).

When you create a Kid object, memory is allocated for a Kid object. Then,
the constructor for the Parent class initializes that part of the new Kid
object which is declared within the Parent class. Then, the constructor for
the Kid class is executed, initializing any members which were declared in
the Kid class itself.

So you personally don't create a Parent object, and then create a Kid
object. If you want a Kid object, then you just create one. Because you've
defined Kid as a class publicly derived from Parent, a Kid object can also
be treated as a Parent object (if you're using a reference or pointer
variable). That's called polymorphism. But there's no "pointer" to a
Parent object inside the Kid object. It's just part of the Kid object.

> DO we
> REALLY NEED to create a Parent each time a Kid object is created.
>

You don't do that, the compiler does that. You've declared Kid as being
derived from Parent, so every member that is declared within the Parent
class is _automatically_ part of a Kid object as well.

But, if you really _want_ a pointer to a Parent object inside your Kid
object, then you're talking about a whole different subject, and you
probably didn't want to use inheritence in the first place.

-Howard

On Wed, 21 Sep 2005 05:28:18 GMT, alfps (Alf P. Steinbach)
wrote:

>> Consider (without worrying abt access specifiers)
>> class Kid : public Parent{...};
>
>This says that a Kid is always a Parent, from the moment it's born.

Well, actually the Kid is first a Parent, even before it is born <g>
-- the base class is always constructed first.

"jon wayne" <jon.wayne.01> wrote in message
news:5300
> OK!
> I had this nagging doubt
>
> Consider (without worrying abt access specifiers)
> class Kid : public Parent{...};
>
> Parent::someFunc()
> {
> Kid k;
> }
> ISSUE- this new Kid , while constructing it, can't I make the
> parent of this new kid point to the already existing parent. DO we
> REALLY NEED to create a Parent each time a Kid object is created.

You are saying a Kid IS A parent (which he will eventually be). But I think
you also want to know the kids parents themselves. So there are, in fact, 3
parents. The kid (who is a parent) his father and his mother. Which gets
compounded by the fact that his father was a kid...

You need to think about your heirarchy. Why do you have a kid class in the
first place? Arent' they both, in fact, both kids and parents?

So something like this:

class Person
{
private:
Person* Father;
Person* Mother;

std::vector<Person*> Children;

public:
Person(Person* father, Person* mother): Father(father), Mother(mother)
{};
AddChild(Person* child) { Children.push_back(child); };
}

Now you have within each person a pointer to their father, their mother, and
potential children.

Because, in your stated scenario, not only is a Kid a Parent, but a Parent
is a Kid, hence, they are the same thing.

I use pointers because I'm used to them. I presume you can do the same
thing with references, just not positive on the syntax.