Re: Defining polymorphism vs. overloading

dmw9q@uvacs.cs.Virginia.EDU (David M. Warme)
Wed, 5 Sep 90 10:16:53 EDT

          From comp.compilers

Related articles
[2 earlier articles]
Re: Defining polymorphism vs. overloading wright@gefion.rice.edu (1990-09-02)
Re: Defining polymorphism vs. overloading compilers-sender@esegue.segue.boston.ma.us (1990-09-03)
Re: Defining polymorphism vs. overloading hrubin@l.cc.purdue.edu (1990-09-03)
Re: Defining polymorphism vs. overloading px@fctunl.rccn.pt (1990-09-03)
Re: Defining polymorphism vs. overloading plph@caen.engin.umich.edu (1990-09-03)
Re: Defining polymorphism vs. overloading daveg@near.cs.caltech.edu (1990-09-03)
Re: Defining polymorphism vs. overloading dmw9q@uvacs.cs.Virginia.EDU (1990-09-05)
Re: Defining polymorphism vs. overloading pase@orville.nas.nasa.gov (1990-09-06)
Re: Defining polymorphism vs. overloading tub!wg@relay.EU.net (1990-09-06)
Re: Defining polymorphism vs. overloading pase@orville.nas.nasa.gov (Douglas M. Pase) (1990-09-06)
Re: Defining polymorphism vs. overloading ok@goanna.cs.rmit.OZ.AU (1990-09-07)
Re: Defining polymorphism vs. overloading pardo@cs.washington.edu (1990-09-07)
Re: Defining polymorphism vs. overloading pardo@cs.washington.edu (1990-09-07)
[8 later articles]
| List of all articles for this month |
Newsgroups: comp.compilers
From: dmw9q@uvacs.cs.Virginia.EDU (David M. Warme)
Keywords: design, polymorphism
Organization: University of Virginia Computer Science Department
References: <9008310419.AA06194@karakorum.berkeley.edu> <4c98dcd0b.001a92c@caen.engin.umich.edu>
Date: Wed, 5 Sep 90 10:16:53 EDT

In article <4c98dcd0b.001a92c@caen.engin.umich.edu> Mark Montague writes:


>So I imagine that every expression of the form
> myarray[index]
>is silently transformed into
> *(myarray+index)
>before the compiler even sees it. Even though it probably doesn't happen
>this way for most compilers, this fictional device lets me ignore questions
>of polymorphism and operator overloading in a non-object-oriented language
>such as C.


          This does not remove polymorphism and/or overloading, it merely
transfers the burden onto + and *. The expansion you state is THE
DEFINITION of the operator. A C compiler I wrote does this during
parsing by building two parse-tree nodes (* and +) rather than a
single node for []. The only detail to consider is that the node used
for * in this case is a specially-flavored * that differs in only one
respect from the "normal" * node: error messages say "invalid
subscript", rather than "illegal indirection".


- Dave Warme
--


Post a followup to this message

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