Class efficiency question

I have a general performance question related to some code I am writing.
Consider the following class:

class FuncClass {
public:
FuncClass(unsigned short FunctionCode);
~FeuronClass();
double GetResult();
void Eval(double In1, double In2);

private:
unsigned short FunctionCode;
double Result;
};

FuncClass::FuncClass(unsigned short FunctionCodeIn) {
Result = 0;
FunctionCode = FunctionCodeIn;
}

FuncClass::~FuncClass() {
}

double FuncClass::GetResult() {
return(Result);
}

void FuncClass::Eval(double In1, double In2) {
switch (FunctionCode) {
case 0: // Addition
Result = In1 + In2;
break;
case 1: // Subtraction
Result = In1 - In2;
break;
case 2: // Multiplication
Result = In1 * In2;
break;
default: // Division
if (In2 != 0) {
Result = In1 / In2;
}
} // Imagine there are actually hundreds of different functions like the
four above
}

Every instance of this class is assigned a FunctionCode according to the
function that it needs to perform. The FunctionCode for an instance never
changes for the entire life of the instance. The question I have is whether
a compiler will allocate more memory than necessary for this instance to
accomodate all the functions that the instance _can_ do instead of just
allocating the memory for the one function that it _will_ do. Would it be
more efficient to have many derived classes each with a virtual Eval
function that does only one function so that I would just instantiate the
specific class for the function I want to do? (Really this just means
moving the switch statement out of the class and into the instantiating
code).

Also, would there be any speed benefit in changing my approach, or just a
reduction in memory (or neither) ??

re: Class efficiency question

"Victor Hannak" <victor.hannak@nospam.kodak.com> wrote in message news:bkchkn$def$1@news.kodak.com...[color=blue]
> I have a general performance question related to some code I am writing.
> Consider the following class:
>[/color]
Member functions are shared accross all class isntances. No matter how many FuncClass
objects you create, there is only one Eval function. It's only the non-static data members
you need to worry about.

However, having a switch on some "object type" field generally defeats the whole
purpose of OO. Having derived classes for each operation using a virtual Eval
method would be more OO. Of course, there may be reasons you may not want
to do that (like you want to keep these things in an array or such).

re: Class efficiency question

"Victor Hannak" <victor.hannak@nospam.kodak.com> wrote in message
news:bkchkn$def$1@news.kodak.com...
[color=blue]
> Every instance of this class is assigned a FunctionCode according to the
> function that it needs to perform. The FunctionCode for an instance never
> changes for the entire life of the instance. The question I have is[/color]
whether[color=blue]
> a compiler will allocate more memory than necessary for this instance to
> accomodate all the functions that the instance _can_ do instead of just
> allocating the memory for the one function that it _will_ do. Would it be[/color]

Functions are not allocated per instance like that. If I have classes A1
and A2 that contain the same amount of data, then usually sizeof(A1) ==
sizeof(A2) even if A1 has a hundred functions and A2 has none.
[color=blue]
> Also, would there be any speed benefit in changing my approach, or just a
> reduction in memory (or neither) ??[/color]

How do you know you need to worry about time or memory at this point? Have
you profiled the code to make sure?

Since you're using C++, you should assume OO (which was generally intended
for this kind of thing) is best here, unless you can show (preferably with a
profiling tool) that the performance on your intended platform would be much
better using a switch statement - this is rather unlikely since polymorphism
is _usually_implemented_ in a conceptually similar way, except objects store
virtual table pointers instead of enumerations, and the function is found by
applying an offset to the virtual pointer instead of finding an offset by
way of a jump table.