Re: What's so great about dynamic binding?

barmar@think.com (Barry Margolin)
20 Nov 91 03:32:18 GMT

          From comp.compilers

Related articles
Current work in compiler/language design. hackeron@Athena.MIT.EDU (Harris L. Gilliam - MIT Project Athena) (1991-11-10)
What's so great about dynamic binding? spitzak@girtab.usc.edu (1991-11-19)
Re: What's so great about dynamic binding? pardo@cs.washington.edu (1991-11-20)
Re: What's so great about dynamic binding? mlanett@void.ncsa.uiuc.edu (1991-11-20)
Re: What's so great about dynamic binding? barmar@think.com (1991-11-20)
Re: What's so great about dynamic binding? paj@uk.co.gec-mrc (1991-11-20)
| List of all articles for this month |
Newsgroups: comp.compilers
From: barmar@think.com (Barry Margolin)
Keywords: design, OOPS
Organization: Thinking Machines Corporation, Cambridge MA, USA
References: 91-11-030 91-11-071
Date: 20 Nov 91 03:32:18 GMT

Wouldn't this be more appropriate for comp.object than comp.compilers?


In article 91-11-071 spitzak@girtab.usc.edu (William Spitzak) writes:
>I notice that a whole slew of "hot topics" in object-oriented design were
>listed and that about half of them started with the word "dynamic". This
>concept has always bothered me, because dynamic means interpreted, at some
>level, at least with current machine architectures. If this is true then
>the language should be powerful enought to NOT support dynamic binding, yet
>you can implement any dynamic method you want IN it.


Dynamic != interpreted. Quite often, dynamic just requires a level of
indirection. As in your example:


>I have been programming professionally in C++ for about a year now,
>implementing a GUI library, and have used exactly ONE virtual function.


In which case, I don't think you're getting the real benefits of
object-oriented programming. One of the most useful things you can do
with object-oriented programming is have a general method in a base class
that invokes detail methods that are implemented in derived classes. This
requires that the detail methods be virtual functions. Object-oriented
languages permit more modular programming in this way.


>I also did a rather quick test - by use of a "pointer to a function" in that
>base class, I was able to eliminate even that virtual function.


So what was the benefit? C++ virtual functions are generally implemented
using a hidden function pointer. Each instance contains a pointer to its
class's vtable, and virtual function calls indirect through this and then
through the function pointer.


>The big loss here is that every sub class needed a constructor to fill in
>that field with the correct pointer (the sort of thing we need better
>languages to automate),


Also, your method requires storage in each instance for each virtual
function. Most real C++ virtual function implementations only require one
pointer in each instance, and one per-class vtable. Basically, it's a
time-space tradeoff: your implementation uses a pointer per virtual
function per instance and one level of indirection per call, while the
usual implementation requires one pointer per instance, one pointer per
virtual function per class, and two levels of indirection per call.


> but I quite successfully fully duplicated the function of the
>dynamic-binding with a static langague.


So? The cfront implementation of C++ translates C++ to C, so it obviously
must be able to do this.
--
Barry Margolin, Thinking Machines Corp.


barmar@think.com
{uunet,harvard}!think!barmar
--


Post a followup to this message

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