Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!elroy.jpl.nasa.gov!hacgate!ashtate!dbase!awd
From: awd@dbase.UUCP (Alastair Dallas)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Questions about THINK C v4.0
Summary: Not as C++ compatible as you might think
Message-ID: <194@dbase.UUCP>
Date: 11 Aug 89 21:08:09 GMT
References: <9878@phoenix.Princeton.EDU>
Organization: Ashton Tate Devlopment Center Glendale, Calif.
Lines: 90

In article <9878@phoenix.Princeton.EDU>, bskendig@phoenix.Princeton.EDU (Brian Kendig) writes:
> A few questions about the latest version of THINK's Lightspeed C,
> which apparently is already shipping:
> 
> I've heard a lot of speculation about what it does and doesn't support.
> From what I can gather, it can handle both C code and C++ code.  Is this
> correct?  If it can still handle straightforward C (why wouldn't it?),
> can it deal with ANSI C, or are we still stuck with 'old-style' C?

THINK C 4.0 is almost completely ANSI C conformant.  The few differences are
not important--const and volatile are not supported, for instance, and there
are no #pragmas (the standard doesn't require pragmas).  What _is_ important
is that the differences between 4.0 and the ANSI standard are clearly 
spelled out (using K&R v2, because the standard is still a moving target).

However, I am beginning to get the impression that THINK C's compatibility
with C++ is more coincidence than design.  THINK C does not add reserved
words, such as 'class' or 'public' or 'friend' or (you get the idea).
Instead, certain syntax ('::') is "interpreted specially in context" (I'm
paraphrasing from memory and I must admit I don't understand what is 
meant by the phrase anyway).

The C++ syntax (Stroustrup p32, chosen at random):

	class Vec : public vector {
	public:
		Vec(int s) : (s) {}
		Vec(Vec&);
		~Vec() {}
		void operator=(Vec&);
		void operator*=(Vec&);
		void operator*=(int);
		//...
	};

This points out a few of the concepts that THINK C 4.0 doesn't have (or
perhaps that are not documents):

	class	- say 'struct' in 4.0
	public	- everything is public
	{}	- no inline functions in class definitions
	Vec&	- no references (class instances are handles, just use 'em)
	~	- constructor, destructor methods have no reserved syntax
	operator- no operator overloading

It's hard to see how THINK C 4.0 and C++ can be said to be in the same
compatibility family except for their common roots in C.

> Is it compatible with projects constructed by earlier versions of THINK C
> (again, why shouldn't it be?)?  What's this talk about it being compatible
> with MacApp, and can it get along with MPW 3.0 C code to any extent?

Perfectly compatible with earlier versions of THINK C, but I'm not sure 4.0
is any more comfortable with MPW than 3.0 was.  The Class Library provided
with 4.0 is a MacApp-like experience and there is every reason to hope that
a future release of THINK C will be completely MacApp compatible.

> And what are its assembler capabilities?  Does it have a (good) in-line
> assembler?

THINK C has always (or at least 2.x) had a good in-line assembler, and for
this release they added some stuff about inline 68881 code.  (I'm not too
familiar here.)

> Thankew.
> -- 
> | Brian S. Kendig       |  I feel more like I   | bskendig                   |
> | Computer Engineering  |  did when I got here  | @phoenix.Princeton.EDU     |
> | Princeton University  |       than I do now.  | @PUCC.BITNET               |
> | Systems Engineering, NASA Space Station Freedom / General Electric WP3     |

I am not disappointed at THINK's lack of C++ compatibility, and I'm still
eager to jump in and learn to use the Class Library.  I know a lot of
programmers who feel guilty that they're not learning practical oops, but
will use any excuse to avoid it.  Here comes THINK C 4.0 with a low-cost
entry into oops, but  we don't have to use it--we'll wait for _true_
C++ compatibility.

I got the feeling when ANSI C was in early draft and 3.0 came out with old-
style function declarations that Mr. Kahl had a certain disdain for the
draft standard.  I could almost hear him saying--"that's arbitrary; why
do you need to change that?"  I get the same feeling from 4.0's half-hearted
embrace of Stroustrup's language--"why do you need 'class' when you can
say 'struct'?"  I have a lot of respect for ANSI C and C++, but I've got
a lot of respect for Mr. Kahl, too.  If you keep giving us excellent 
products like THINK C, Mr. Kahl, you can do what you want--but you must
realize that just as 4.0 conforms to the ANSI standard, 5.0 will probably
have to be more like "real" C++.

/alastair/