|Polymorphism vs. overloading firstname.lastname@example.org (Ralph Johnson) (1990-09-09)|
|Re: Polymorphism vs. overloading email@example.com (1990-09-12)|
|Re: Polymorphism vs. overloading firstname.lastname@example.org (1990-09-14)|
|Polymorphism vs. Overloading email@example.com (1994-10-22)|
|Re: Polymorphism vs. Overloading firstname.lastname@example.org (1994-10-22)|
|Polymorphism vs. Overloading email@example.com (1994-10-27)|
|Re: Polymorphism vs. Overloading firstname.lastname@example.org (1994-10-24)|
|Re: Polymorphism vs. Overloading email@example.com (1994-10-28)|
|Re: Polymorphism vs. Overloading firstname.lastname@example.org (1994-10-28)|
|[28 later articles]|
|From:||email@example.com (Markku Sakkinen)|
|Organization:||University of Jyvaskyla, Finland|
|Date:||Fri, 14 Sep 90 09:17:38 +0300|
In article <9009100341.AA17336@m.cs.uiuc.edu>
firstname.lastname@example.org (Ralph Johnson) writes:
> [...] In fact, late-binding can be considered to be
>normal polymorphism, i.e. a procedure that can take arguments of
>many different types.
>Consider the C++ expression figure->display(). This can be thought
>of as "select the right function for the type of figure and run it",
>in which case one might think that it was like overloading, i.e.
>there are several different procedure definitions and one of them
>is being selected based on the type of one of the arguments. However,
>it is more correct to think that it means to retrieve a field of
>record figure, which is a pointer to a function, and execute the
>function to which it points. In this case, the function being
>executed can be of one of several types. [...]
This is somewhat inexact for C++. I would like to adjust
1. In an expression like the above, the variable 'figure'
cannot be a record (structure, class object) but a pointer to such.
2. The function that gets executed _cannot_ be of one of several types,
it must be of the type that has been declared for 'display'.
3. The explanation, "... to retrieve a field of record figure,
which is a pointer to a function ...", is correct _if_ the field
'display' has indeed been declared as a _pointer_ to function
in the class definition. This is fully possible already in C
without needing C++. In C++, 'display' would then be a "data member"
(instance variable) and not a "member function" (instance method)
of the class. - BTW, I think that the implicit dereferencing of
a function pointer that happens here is a bad feature.
3 bis. If 'display' has been declared as a _virtual_ member function
in the class definition, we do have a case of ordinary object-oriented
(and more specifically, class-based) late binding.
The variable 'figure' may point to an instance of any (public)
subclass of its declared class, and the version of 'display'
defined in the "lowest" (most specialised) subclass will be invoked.
In this case there is no pointer-to-function field corresponding
to 'display' in the object itself!
Department of Computer Science and Information Systems
University of Jyvaskyla (a's with umlauts)
SF-40100 Jyvaskyla (umlauts again)
SAKKINEN@FINJYU.bitnet (alternative network address)
Return to the
Search the comp.compilers archives again.