1. It depends on which functions you use. You will certainly have to recompile the code on the new machine. You may or may not be able to directly reuse the code. Generally, you should try to separate the user interface code from the functional code; if you code the functional parts using only standard C++, then you only need to rewrite the interface code (which varies depending on operating system) and recompile.
2) Virtual functions are the key to abstraction. The idea is to create a base class, which you expand upon in child classes.
For example, I have the functionality to take a bitmapped image and reduce the number of colors in an intelligent manner. The Reduce() function takes a pointer to an object of type RGBImage.
In actuality, RGBImage is only an abstract class. Abstract classes have at least one of a special type of function called a
pure virtual function, and you cannot create an object from them.
The only thing you can do with abstract classes is create children from them. For example, my BmpImage class is a child of RGBImage.
A child of an abstract class must implement all pure virtual functions. It MAY implement virtual functions that are not purely virtual.
A function that is
virtual means that whatever the class of the OBJECT, the corresponding function will be called. Otherwise, the class of the POINTER determines it.
Maybe this makes more sense:
Code:
class Parent{
public:
void FunctionOne(){
printf("Parent::FunctionOne");
}
virtual void FunctionTwo(){
printf("Parent::FunctionTwo");
}
};
class Child : public Parent{
public:
void FunctionOne(){
printf("Child::FunctionOne");
}
void FunctionTwo(){
printf("Child::FunctionTwo");
}
};
Now, if you did the following:
Parent * c = new Child(); // you can make a pointer to Parent point to Child because Parent is a base class of Child.
If you executed c->FunctionOne() it would print "Parent::FunctionOne()" because the function is not virtual and it only considers the class of the pointer.
If you executed c->FunctionTwo() however, it would print "Child::FunctionOne()" because the actual object is a Child, and virtual functions call the OBJECT'S copy of the function.
This is really helpful when you want to make an interface class to reuse code. That's why my RGBImage class has all of its functions virtual. I know that I can take a pointer to an RGBImage (which will in fact point to some derived class, maybe BmpImage, maybe something else) and I can use, say GetImageDimensions() and know that, assuming the derived class implements the interface properly, it will return the appropriate dimensions.
This way, if I wanted to reduce the colors of, say, a GifImage object, I can make GifImage a subclass of RGBImage and implement the few functions that I need to implement, and it will work exactly as it should.
3. I don't understand the question
4. and 5. are already answered quite nicely.
[Edited by Paul Victorey on 02-05-2001 at 10:54 PM]