Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!lll-winken!sun-barr!newstop!sun!amdahl!key!perry
From: perry@key.COM (Perry The Cynic)
Newsgroups: comp.sys.mac.programmer
Subject: Re: MPW C++ vs. THINK C 4.0
Message-ID: <2077@key.COM>
Date: 23 Aug 90 18:59:11 GMT
References: <2054@key.COM> <3947@husc6.harvard.edu> <2070@key.COM> <9896@goofy.Apple.COM>
Reply-To: perry@arkon.key.COM (Perry The Cynic)
Organization: Key Computer Laboratories, Fremont
Lines: 41

In article <9896@goofy.Apple.COM> lsr@Apple.COM (Larry Rosenstein) writes:
> As far as virtual overhead goes, C++ requires that the programmer make a
> decision about virtual/non-virtual for each member function.  The programmer
> has to decide up front whether a user of the class would want to override a
> function.  In Object Pascal (don't know about THINK Pascal/C), this
> optimization is made in the linker, based on how the class is used.  If the
> function isn't overridden then there is no virtual dispatching overhead.

The problem is not (so much) member call dispatch overhead. The problem is
the notion that every *class* necessarily needs virtual dispatching in the
first place. One of the great things about C++ is that I can make encapsulated
types that are *not* meant to be heap nodes. I can create
	class boundedInt {
	 ...
	private: int value;
	};
with no virtual members at all, and the compiler will happily lay it out as
an int with no storage overhead. Together with inline access functions I can
implement a notion of bounded integer with a low enough overhead to use in
place of unbounded ints. I would not try that if all my boundedInt's would
take 4 bytes more (for a virtual table pointer), or if I had to make Init calls
for all those integers in my program(!).
Note that boundedInt's follow a *value* concept, NOT a *reference* concept.
This whole idea does of course not fit with Object Pascal, where an object is
inherently heap based and reference-oriented (in the SmallTalk sense). C++
classes are meant (IMHO) to implement "abstract data types", which is a true
superset of "OOP objects".

Note that in C++ you are still free to separate allocation and construction
if you so choose. Just use a separately named constructor function. On the
other hand, you can provide implicit initialization where appropriate. In my
experience, the ability to *force* initialization during creation eliminates
many coding problems, esp. in multi-person projects.

Unfortunately, Symantec's Object C is like Object Pascal, *not* like C++,
in this respect.
  -- perry
-- 
--------------------------------------------------------------------------
Perry The Cynic (Peter Kiehtreiber)		       perry@arkon.key.com
** What good signature isn't taken yet? **  {amdahl,sgi,pacbell}!key!perry