Jeff said:
Is there a practical reason to do this? The fact that a square is a
rectangle does not mean that class Square must be derived from class
Rectangle. This sort of design is typically inefficient. The reason is
that the derived classes don't need the generality that likely will be
provided by the base class. For example, you said Quadrilateral "takes"
four vertices. If those vertices are stored in member variables, then
by deriving Square from Quadrilateral, you force Square to remember all
four vertices. These members will be wasted in Square, since a Square
can be defined by one vertex and a side length.
In order to do what? For what do you expect to use these classes?
Amen! This is a truly disgusting assignment. It is wasteful of memory and
human neurons. It gives the student no insight whatsoever into inheritance
and and how it might be useful instead of an impediment to doing something
interesting and perhaps even useful.
To the OP: {I have read your second post too, the link here is not
chronological)
Presumably, at some point you will be able to compute the perimeter and area
of these four plane figures. That seems a reasonable goal. But it seems
you need some context. IOW, are you (main) to be given four vertices and
determine *what* to construct? Or are you given two vertices and told that
this is to be a square? Looking at your code I see you assume main gets
four vertices and the additional information in the name of the resulting
figure. It sounds a bit like cheating (no insult intended) but someone has
to go through hell to call the constructor and then the thing you wrote goes
through another hell to unwind this complicated mess. Do you see my point?
That is, what is the nature of the *driving* program/problem/whatever? One
candidate: you are given four vertices and told it is a square. Your code
determines if it is indeed a square or if the caller had lied to you. And
proceeds accordingly.