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, butwe 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/