Newsgroups: comp.object
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!barmar
From: barmar@think.com (Barry Margolin)
Subject: Re: Negative Reaction to OOT
Message-ID: <1991May15.054458.27897@Think.COM>
Sender: news@Think.COM
Reply-To: barmar@think.com
Organization: Thinking Machines Corporation, Cambridge MA, USA
References: <10954@rama.UUCP>
Distribution: na
Date: Wed, 15 May 91 05:44:58 GMT

In article <10954@rama.UUCP> jec@rama.UUCP (Judy Chapman) writes:
>Here is a co-workers opinion on OOT. I am trying to promote  
>the use of OOT - how do I respond to this??
>	1) Speed.  

With many current OO language implementations, there is some amount of
performance traded off for the software engineering benefits of OO
programming.  Is this list in priority order?  If so, you may have a hard
time convincing this guy that OO programming is a good thing.

>        b) Check speed of member function invocation/execution to 
>           that of conventional data abstraction mechanisms to establish
>           cost of dynamic Object-->Function invocations.

Be careful with this comparison, as it's easy to compare apples with
oranges.  It's not fair to compare generic function invocation with
ordinary fuction invocation, because generic functions are doing much more.
It's more appropriate to compare generic function invocation with a case
statement where each case invokes a function, since that is the most
similar conventional programming construct.

>	2) Use of Dynamic Memory.  
>
>	    a) How much memory is wasted on function pointers to functions.
>           Is it allocated once per object, or once per object type.  Is
>           this compiler dependent ?

Many languages only need at most a single per-object pointer to a per-type
function table.  C++ only needs this if virtual functions are used.  Of
course, a compiler can do it anyway it wants to, so it's compiler dependent
whether a particular implementation actually uses only this much (but I
think most of them do).
-- 
Barry Margolin, Thinking Machines Corp.

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