Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!uxc.cso.uiuc.edu!uxc.cso.uiuc.edu!ux1.cso.uiuc.edu!uxa.cso.uiuc.edu!jpd00964
From: jpd00964@uxa.cso.uiuc.edu
Newsgroups: comp.sys.mac.programmer
Subject: Re: Comments on THINK C 4.0
Message-ID: <227700029@uxa.cso.uiuc.edu>
Date: 15 Aug 89 21:19:00 GMT
References: <10362@fluke.COM>
Lines: 46
Nf-ID: #R:fluke.COM:10362:uxa.cso.uiuc.edu:227700029:000:2158
Nf-From: uxa.cso.uiuc.edu!jpd00964    Aug 15 16:19:00 1989


/* Written  3:42 pm  Aug 14, 1989 by mce@tc.fluke.COM in uxa.cso.uiuc.edu:comp.sys.mac.programmer */
/* ---------- "Comments on THINK C 4.0" ---------- */
> Some quick initial comments:
>	2) The new() operator does no type checking.  You would like for
>
>		CMyApplication gMyApplication;
>		...
>		gMyApplication = new(CApplication);
>
>	   to cause a compiler error, but it doesn't (this type of error can
>	   be a good way to crash your machine). 

You do not want the new operator to do type checking like that.  It should 
be extremely easy to allow different objects to be assigned any variable.
For example, assume an object called holder.  Subtypes of Holder can be cup,
box, sack, etc.  Each of these have identically named routines that act
differently.  You should easily be able to have one variable that could be
any of those.

>	4) It's deceptive to call it a C++ subset; the list of C++ features
>	   not implemented encompasses nearly the entire C++ language!  It
>	   does not have operator overloading, references, constructors,
>	   destructors, private data, friends, inlines, or, of course, all
>	   the version 2.0 features (multiple inheritance, etc).

I think that was known for quite some time no matter how much smoke was blown
over this issue.  Claiming Upward compatable was so much Blown Smoke that it
almost made some people ill (me for one :->).  

>	   Actually, you could say that the philosophy behind C++ is opposed
>	   to that of the Macintosh.  Stroustrup has said that "features that
>	   would incur run-time or memory overheads even when not used were
>	   avoided".  Objects in handles are an obvious need for Macintosh
>	   programs, and just as obviously heretical to the rest of the C++
>	   community.

The Macintosh philosophy changes over time.  Some things will remain the same
forever, (such as mediocre to poor support for developers) but this aspect
will change.  Actually, OOP is very mac like.  The traps are almost (not the 
word almost) a precursor to OOP philosophy.  The actual routines were able
to be changed entirely transparent to the program.  This is the same for
OOP.

Michael Rutman
Softmed