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