PO> NO there is a CLASS employee and the object is employee1.
PO> The employee class looks somehing like:
PO> class employee
PO> {
PO> char name[20];
PO> int age;
PO> float salary;
PO> employee (char, int, float); /*constructor*/
PO> void print_employee(); /*print function*/
PO> };
PO> all admin does to employee is up his salary.
The name is Kermit... ( sheesh... )
Unless declared public:, the members of a class are, by
default, private:. I am surprised, if this is the problem,
that you did not get an error on compiling. Nearly any
compiler will blow the whistle at this point and shout,
"foul!" At any rate, the code to manipulate data within the
employee class should reside within that class, and only the
admin should have the ability to access that class, though
you might have the task also handled by BkKeeping in the case
of periodic or contractual raises.
It should probably look more like this:
void Admin::Raises(Employee &cEmp)
{
cEmp.AdjustIncome(1.75f);
}
or, perhaps, like this:
void Admin::Raises(Employee &cEmp)
{
cEmp.SetIncome(1.75f * cEmp.GetIncome());
}
In this manner, the employee class can also contain all the
code to make sure that the data is reasonable. This makes for
a more reliable class, because it will always contain valid
data, even if Admin or BkKeeping should screw up.
It may not always contain CORRECT data, mind you. That is
still vulnerable to error, but it will not contain any data
which will crash your program with something such as a
divide by zero error or some other possible fatal bug.
Also, if you are reading from a configuration file, and, upon
reading in data to the employee class you check the salary
against the minimum wage found in your configuration, you can
skip changing them manually. Just loading them and saving
them can perform the update automatically. The result is a
more powerful and robust class implementation.
> ] Love is not blind, but sometimes it looks the other way.....
---
---------------
* Origin: *YOPS ]I[* 8.4 GIG * RA/FD/FE * Milwaukee, WI (1:154/750)
|