Re: Polymorphism vs. overloading (Markku Sakkinen)
Fri, 14 Sep 90 09:17:38 +0300

          From comp.compilers

Related articles
Polymorphism vs. overloading (Ralph Johnson) (1990-09-09)
Re: Polymorphism vs. overloading (1990-09-12)
Re: Polymorphism vs. overloading (1990-09-14)
Polymorphism vs. Overloading (1994-10-22)
Re: Polymorphism vs. Overloading (1994-10-22)
Polymorphism vs. Overloading (1994-10-27)
Re: Polymorphism vs. Overloading (1994-10-24)
Re: Polymorphism vs. Overloading (1994-10-28)
Re: Polymorphism vs. Overloading (1994-10-28)
[28 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers
From: (Markku Sakkinen)
Keywords: polymorphism, C++
Organization: University of Jyvaskyla, Finland
References: <>
Date: Fri, 14 Sep 90 09:17:38 +0300

In article <> (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
three points.

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!

Markku Sakkinen
Department of Computer Science and Information Systems
University of Jyvaskyla (a's with umlauts)
Seminaarinkatu 15
SF-40100 Jyvaskyla (umlauts again)
                    SAKKINEN@FINJYU.bitnet (alternative network address)

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.