Path: utzoo!attcan!utgpu!watmath!att!dptg!rutgers!usc!elroy.jpl.nasa.gov!ames!ncar!husc6!mit-eddie!apollo!lsmith From: lsmith@apollo.HP.COM (Lawrence C. Smith) Newsgroups: comp.sys.mac.programmer Subject: Re: C++ for the Mac Message-ID: <44ea056a.1199f@apollo.HP.COM> Date: 8 Aug 89 23:01:00 GMT References: <2278@husc6.harvard.edu> <786@cbnewsk.ATT.COM> <4400@tekred.CNA.TEK.COM> Reply-To: lsmith@apollo.COM (Lawrence C. Smith) Organization: Hewlett-Packard Company, Apollo Division; Chelmsford, MA Lines: 56 In article <4400@tekred.CNA.TEK.COM> jasons@frosty.CNA.TEK.COM (Jason Scheck) writes: >I just got my Think C 4.0 upgrade notice, and found it to be somewhat >confusing. I quote the last two lines of one of the paragraphs in the >letter. > >> The object extensions inTHINK C are similar to Object Pascal as defined >> by Apple Computer. The syntax is based on C++, and is upwardly >> compatible with C++. > >The last sentence gets me. From what has been set on this newsgroup, >Think C doesn't support operator overloading, among other C++ >features. So how is it that its _syntax_ is compatible with C++, >without having its features. For instance, if I give it the text: > > class A > { > public: > ... > A& operator=(int); > ... > }; > >which is syntax accepted by cfront, how can Think C accept it without >supporting operator overloading. Was some marketing person at Symantec >somewhat overzealous? > >Jason Scheck >jasons@tekred.CNA.TEK.COM Obviously, it can't. "Upwardly compatible" is a polite marketspeak way of saying the product in question is a "strict subset". That means, whenever both THINK C 4.0 and C++ have a feature in common, THINK C will accept the same syntax. Since both have objects, we can therefore presume that: class A { public long foobar(); } will be accepted by THINK C just as C++ accepts it. However, where they do not have features in common, no syntax is acceptable, your example fragment would be rejected. The promise of compatibility is important, though. Programs can be developed on THINK C and they *will* port to C++. However, C++ programs will *not* port to THINK C until more C++ features are added. The promise means that as the new features are added, they will be added in C++-compatible syntax. Someday, THINK C will therefore be C++-compliant. This is all perfectly standard English, Jason. Symantic hasn't made *any* wild claims. -- Larry Smith lsmith@apollo1.UUCP or {mit-eddie,yale,uw-beaver}!apollo!lsmith