child class as argument?

[mwebel]

Hi,
i have another problem:
i have a container basis class and want to write a virtual "copyFrom()"
function.
Basically the child class should copy from another child class.
************************
class Basis{
public:
virtual void copyfrom(basis & obj)=0;


}


class Child: public Basis{

public:
int x;
void copyfrom(Basis & obj){

//Problem is Basis has no element "x"!!
x=obj.x;
};

}
************************
(i know x should not be public... just to lazy to write getter)
thing is:
how can i write the basis class already so that it'll accept the future
child of it as an argument?
or is it not a problem? can i just do it?
thanks for any answers...

 

[mlimber]

Hi,
i have another problem:
i have a container basis class and want to write a virtual "copyFrom()"
function.
Basically the child class should copy from another child class.
************************
class Basis{
public:
virtual void copyfrom(basis & obj)=0;


}


class Child: public Basis{

public:
int x;
void copyfrom(Basis & obj){

//Problem is Basis has no element "x"!!
x=obj.x;
};

}
************************
(i know x should not be public... just to lazy to write getter)

First of all, it's not necessary for a member function, and second it
took just as long to write your disclaimer. ;-)

thing is:
how can i write the basis class already so that it'll accept the future
child of it as an argument?
or is it not a problem? can i just do it?
thanks for any answers...

What you are asking doesn't make a lot of sense to me. Consider this:

class Shape
{
public:
virtual void CopyFrom( const Shape& ) = 0;
};

class Circle : public Shape
{
int radius_;
public:
virtual void CopyFrom( const Shape& );
};

class Polygon : public Shape
{
int sides_, height_;
public:
virtual void CopyFrom( const Shape& );
};

How do you propose to have a circle copy from a polygon when their
implementations are different even in terms of the number and semantic
meaning of their data members? If they were more similar, you could
either move their similarities into the base class or insert an
intermediate base class with their shared properties (which would allow
for other Shapes that don't share in those properties).

You might be seeking the Visitor design pattern.

Cheers! --M

 

[dj]

First of all, it's not necessary for a member function, and second it
took just as long to write your disclaimer. ;-)


What you are asking doesn't make a lot of sense to me. Consider this:

class Shape
{
public:
virtual void CopyFrom( const Shape& ) = 0;
};

class Circle : public Shape
{
int radius_;
public:
virtual void CopyFrom( const Shape& );
};

class Polygon : public Shape
{
int sides_, height_;
public:
virtual void CopyFrom( const Shape& );
};

How do you propose to have a circle copy from a polygon when their
implementations are different even in terms of the number and semantic
meaning of their data members? If they were more similar, you could
either move their similarities into the base class or insert an
intermediate base class with their shared properties (which would allow
for other Shapes that don't share in those properties).

You might be seeking the Visitor design pattern.

Cheers! --M

I suppose the abstract CopyFrom in the base class forces all derived
classes to implement it. How about forward declaring the child class so
you can use it in the declaration of the base class? But this could be
inelegant with many child classes. Perhaps it is better to let the
CopyFrom use the base class argument and use dynamic cast to change it
into any type the derived class can copy from.

 

[mwebel]

I suppose the abstract CopyFrom in the base class forces all derived
classes to implement it.

Yes, thats exactly what it want:
just a unified API for all child classes!
that way i can re-use alot of code afterwards by changing jsut the
child class type.

How about forward declaring the child class so
you can use it in the declaration of the base class? But this could be
inelegant with many child classes.

Yep, there are going to be 5 or 6 different childs.

Perhaps it is better to let the
CopyFrom use the base class argument and use dynamic cast to change it
into any type the derived class can copy from.

Thats what i did first... but i am not happy with it since its a public
method. Im "losing face" casting on public level.

Now im thinking of just deleting the copy class and put a small
readme.. asking ppl to implement such a class. but thats so dull...

im not sure if the visitor pattern is such good idea.

 

[mlimber]

Yes, thats exactly what it want:
just a unified API for all child classes!
that way i can re-use alot of code afterwards by changing jsut the
child class type.



Yep, there are going to be 5 or 6 different childs.


Thats what i did first... but i am not happy with it since its a public
method. Im "losing face" casting on public level.

Now im thinking of just deleting the copy class and put a small
readme.. asking ppl to implement such a class. but thats so dull...

im not sure if the visitor pattern is such good idea.

Why don't you describe in greater detail what you are trying to do?
(Providing a more substantial code sample could also be helpful.) Then
we might be able to suggest some more options.

Cheers! --M