There are so many errors (e), cases of bad design (d), and probable semantic errors (s) in addition to the initialization that I decided to make a separate posting:
(d) class
hexa
: member variables should almost always be
private
, not protected! Only methods should be
protected
or
public
.
(s) method
hexa::set()
: while your code will compile, if your compiler is any good, it should issue a warning, saying that
x
and
y
are used without being initialized. Then again, it may not because they are not local variables. While it is possible that you initialize them elsewhere before calling set, it would be much safer and clearer to pass the values for x and y as function arguments!
Also, the x and y values you assign make an odd pattern, that is not a hex at all, it is a slanted S-shaped curve..
(d) the function
hexa::disp()
has nothing at all to do with the class hexa. Why is it defined as a method in hexa?
(d) class
red
is derived from the base class,
hexa
. However, there are no virtual functions defined in hexa. That means there is no function you can override, and therefore no reason for inheritance. Inheritance is used when several classes share a common behaviour, and behaviour is expressed through methods, not member variables.
If your intention was to share the coordinates, then include a member variable of type hexa rather than inheriting from it!
(e,d,s)
int a1=(x1=x=30,y1=y=15),b1=(x2,y2),c1=(x3,y3),d1=(x4,y4),e1=(x5,y5),f1=(x6,y6);
Ouch! Now, that single line has so many errors in it it's hard to understand what your intention was:
1. the value of the expression
(A,B)
is always
A
. The compiler will evaluate
A
if it is an expression, and it may evaluate
B
if it is an expression. Anyway, if you assign that expression,
B
is irrelevant, as the result is always
A
.
Given that, using this syntax only makes sense in some very rare, specific cases. More likely, you intended something completely different, and this is not what you wanted.
2. The values
x, y, x1, y1,
etc., do not exist. Not yet, anyway. These variables are member variables of the
type hexa
, and the only way to access the
values stored therein, is create an
instance of that type! This code is placed within the
declaration of the class. The class declaration is like a blueprint: every time you need an instance of this class, you use the class name as the type, and the runtime system will then create an object according to the declaration.
(s,e) The following line almost certainly does not do what you expect:
int ptr1[14]={a1,b1,c1,e1,f1,a1};
What it does is define an array big enough to contain 14 int values, and the first 7 values are initialized with the values of the int variables a1 through f1 and a1.
Or, rather, they would be, if a1 through f1 were defined as constants! You cannot initialize any variable with a value that can only be known at runtime, so here is another case of initialization error!
Judging by the preceding lines, what you intended is an array of 7
pairs of values to be assigned to this array. For that purpose, you either need 14 individual variables, or 7 arrays of 2 variables each. The resulting array can then either be a simple array for 14 values as you defined it here, or a two-dimensional array for 2x7 elements. Since you are using that array as an argument to the function
draw_poly()
, which form you need depends on that function (you didn't include that function in your code).
(d) The functions
draw1_poly()
,
draw2_poly()
, etc. completely and utterly ignore the concepts of object oriented programming. Even more, these functions
could take advantage of your hierarchie of classes, that otherwise has no reason to exist at all. But you forwent that opportunity.
Besides, there is no reason at all to use different names: no matter whether you do or do not use a class hierarchy, you can use the same name for these functions, as their full name (that the compiler internally uses) implicitely includes the class name as well.
On another note, what is that function
draw_poly()
you are using there?
(e?) The line
char colour,red,blue,green,yellow;
defines variables using the same names you already used for your classes. I am not sure this is in fact legal (i. e. accepted by the compiler), but at the very least, it is very, very confusing and a huge source of errors.
Do not do this! You should use different names for variables and types/classes. And when I say different, I don't just mean using lowercase/uppercase (as C++ is case sensitive, that would actually work) - use really different names that you can't accidentally mistake for another with a simple typo.
(e,s)
cout<<1. red<<endl<<2. blue<<endl<<3. green<<endl<<4. yellow;
You omitted the quotation marks.
But what's worse, after that line you omitted reading the response, so the value of the variable
colour
is undefined.