Re: "Virtual functions allow polymorphism on a single argument" ?
On May 11, 3:52 pm, desktop <f...@sss.com> wrote:
James Kanze wrote:
On May 11, 12:07 am, desktop <f...@sss.com> wrote:
In practice, in C++, this can be implemented by calling a
virtual function on the first object, and having it call a
virtual function on the second. But with the constraint that
the base class has to know of the existance of all of the
derived types.
Ok, if we have obj.callMe(arg) the "first" makes sure to find the right
"owner" of obj and uses the virtual functionality to accomplish this.
The "owner object" has as many callMe(arg) functions (specified as
virtual in an abstract base-class) as there are different types of "arg"
objects. In the owner object it could look like this:
callMe(Ball) {}
callMe(Plane) {}
callMe(Bus) {}
callMe(Toy) {}
The "second" call as I understand is just a matter of finding the right
function matching the called argument "arg" through the overloaded
function callMe.
You say that multiple-arg polymorphism deals with two virtual calls, but
are the second not just a regular call to an overloaded function?
No. The first virtual function call resolves the type of the
first object. It ends up in a function of this type, with a
fully typed this. It then calls a virtual function on the
second object, which takes the resolved type as argument. All
of the functions must be present and virtual in the base class,
so we get something like:
class Vehicule
{
public:
virtual void collideWith( Vehicule& other ) = 0 ;
virtual void collideWith( Car& other ) = 0 ;
virtual void collideWith( Bus& other ) = 0 ;
virtual void collideWith( Truck& other ) = 0 ;
// ...
} ;
class Car : public Vehicule
{
public:
virtual void collideWith( Vehicule& other )
{
other.collideWith( *this ) ;
}
virtual void collideWith( Car& other )
{
// Car vs. Car...
}
virtual void collideWith( Bus& other )
{
// Bus vs. Car...
}
virtual void collideWith( Truck& other )
{
// Truck vs. Car...
}
} ;
Vehicule* pCar = new Car ;
Vehicule* pBus = new Bus ;
pCar->collideWith( *pBus ) ;
So what happens here. First, the compiler decides *statically*
which function is to be called (overload resolution), in
Vehicule. Since the argument has the static type Vehicule
(because it is a Vehicule* which is dereferences), the compiler
chooses Vehicule::collideWith( Vehicule& ). Overload resolution
is *always* based on the static type. Since this function is
declared virtual, virtual dispatch occurs, and as a result, we
end up in Car::collideWith( Vehicule& ). But all this does is
call collideWith on the other object. So we start over:
overload resolution in the base class. Except that this time,
the argument is *this, this is a Car* (and not a Vehicule*), so
oeverload resolution chooses Vehicule::collideWith( Car& ) (and
not Vehicule::collideWith( Vehicule& ), as it did the first
time. Again, this function is declared virtual, so virtual
dispatch is applied to "other"; since the actual type is a Bus,
we end up in Bus::collideWith( Car& ) (which I haven't shown).
Basically, each dynamic dispatch works on a single object.
Using this pattern, the first dispatch serves to get us into a
context where the static type is the same as that as the first
object. We then inverse the call, so that the second static
dispatch will call a function based on the type of what was
originally the second argument, with the already resolved type
being used to choose the correct function, by means of overload
resolution.
--
James Kanze (Gabi Software) email: james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34