Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!usc!apple!lsr
From: lsr@Apple.COM (Larry Rosenstein)
Newsgroups: comp.sys.mac.programmer
Subject: Re: MPW C++ vs. THINK C 4.0
Message-ID: <9896@goofy.Apple.COM>
Date: 22 Aug 90 23:57:20 GMT
References: <2054@key.COM> <3947@husc6.harvard.edu> <2070@key.COM>
Organization: Apple Computer, Inc.
Lines: 37

In article <2070@key.COM> perry@arkon.key.COM (Perry The Cynic) writes:
>
>I didn't know that Apple actually perpetrated this "C+-" idea. Ah well.
>Yes, "Object C" feels for all the world like an "Object Pascal" programmer's
>idea on how to extend C. I can see how it got conceived; maybe they just
>wanted an objectified C that could easily interface to MacApp. (And then they
>turned around and implemented full C++...)

The official name is Minimal C++.  

That was the basic idea.  It provided an intermediate target for developers
who wanted to support MacApp but didn't want to support full C++.  (Also,
I'm not sure what the state of C++ was at the time this spec was written.)

>construction and destruction doesn't exist in C+- at all. Making an Init call
>for each object-typed field of a struct object I'm creating is not my idea of
>fun. Besides, it's error prone. Besides, it always has virtual overhead.

The explicit Init call has the advantage that initialization is separated
from allocation.  In the current version of C++ it is more difficult to
recover from a failed constructor.

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.




-- 
		 Larry Rosenstein,  Object Specialist
 Apple Computer, Inc.  20525 Mariani Ave, MS 46-B  Cupertino, CA 95014
	    AppleLink:Rosenstein1    domain:lsr@Apple.COM
		UUCP:{sun,voder,nsc,decwrl}!apple!lsr