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