bskendig@phoenix.Princeton.EDU (Brian Kendig) (08/10/89)
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? 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? And what are its assembler capabilities? Does it have a (good) in-line assembler? 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 |
minow@mountn.dec.com (Martin Minow) (08/10/89)
In article <9878@phoenix.Princeton.EDU> bskendig@phoenix.Princeton.EDU (Brian Kendig) writes: > >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? It's about 90% compatible with Ansi C (the libraries are compatible, and there are one or two not-particularly important compiler features left out. Note that ANSI C is not yet an approved standard and still subject to change. > >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? You have to convert existing projects (no going back, I suspect). This is relatively painless, but if you added home-made prototypes for string and stdio functions, you'll have to do some editing. Also, some of the oddball libraries (strings, storage) are now in the ansi library. I.e., some assembly is required. I converted a large program to V4 in about 15 minutes. >And what are its assembler capabilities? Does it have a (good) in-line >assembler? Supposed to be "spiffy" -- it works together with the C compiler, and understands branch length, among other things. See below. My copy came yesterday. Here are some notes from a talk Mike Kahl gave to Boston Computer Society last month that apparently didn't escape from mountn [late notes in brackets]: Symantec previewed Think C 4.0 to the Boston Computer Society on July 5. Here are some rather incoherent notes from Mike Kahl's talk. (Mike is the primary developer). -- Important stuff first: release date end of July (*very* end of July), 4 disks, no price change ($249 list, $69 upgrade). (Perhaps he meant "no price change for upgrades"?) [It's out now. 4 disks and 2 manuals. Several demo programs including a MacPaint clone.] -- Object oriented enhancements. O.O. is not difficult, but it is a different way of thinking about programming. "Reusablility of code" is the central idea. In a typical program, libraries are at the lowest level of the call tree. However, the Mac's event-driven operating system design makes the *top* of your programs the same. Now the bottom is different. Object Oriented programs lets the "bottom" call back to higher levels. Doing this in normal programming languages is ugly and inconvenient: usually it's too much bother. Object oriented programming lets you write libraries in the "middle" of your application. Great for the Mac interface. -- Think C includes a full class library (included in source format) and language support for objects. The class library includes all the Mac junk (clipboards, printing, windows, scrolling) along with a mini text editor. [The library is huge. The demo programs compile it with your application. I hope you can build a precompiled library. I have a lot to learn.] Each window is an object "Pane". It contains sub-classes: ScrollBars, SizeBox, Content, and Totality (which includes everything). (There's a Panorama here, too. It's a subclass of Pane plus specific behavior. My notes are somewhat incoherent here.) The ScrollPane object knows how to connect the scroll bars (etc) with the Content. When the user clicks in a scroll bar, it sends a message to the parent (ScrollPane). ScrollPane sends a message to Panorama. Neither ScrollBar nor ScrollPane know what is being scrolled. Panorama doesn't know whether the user clicked in the arrow or dragged the thumb. There are three hierarchies in an object-oriented program: Visual: dynamic -- changes as the user works with the application. Class: compiled -- defines inheritance of behavior. Command: how messages flow (mostly follows visual). Objects are handles: they change size when you add subclasses. [There are some behind-your-back dereferencing mechanisms, too. Reading the documention looks important.] -- Think C is a subset of C++. You can write programs that are transportable, but it is not a strict subset. All methods are virtual, for example. This is *not* C++. ("maybe someday") This is "object extensions to Think C" Object Oriented Programming for the Mac. Based on Object Pascal. -- Language/library changes: The library is 100% Ansi conformat. Also, it appears much easier to use. You can get a command line interface by adding two lines to main(): #include <console.h> main(argc, argv) ... argc = ccommandline(&argv); This puts a dialog on the screen letting you enter a command line and do I/O redirection. The compiler is 95% Ansi conformant: + full prototype support. + full preprocessor support. - no const or volatile support. - signed/unsigned subtilties (Hex constants sign don't sign extend now, or maybe they do sign extend now.) + code resource enhancements. multi-segment code resources. multi-word inline includes (easier to handle ScriptManager glue, for example). You can build XCMDS, DA's, and drivers etc. directly. There's a CDEV shell procedure. - still 32K global data limit. "Spiffy" new inline assembler. Supports '020, '881. Branch optimization, dc.w function name (for device drivers?) external entry points. Linker checks for library changes. You can build code resources into existing files (Hypercard XCMD's for example). -- New, huge manual. [700 page user manual, 200 page library manual. The O.O. stuff is in the user manual. I think they should have had three manuals.] -- No changes to RMaker. (Grumble.) [They include some ResEdit templates for O.O resources. I'm not sure how they fit together. Also unsure how my stuff (using RMaker works with their resources.] -- Corridor conversation: not impossible that they'll retarget the compiler to some other hardware base. Note: I don't really understand everything that I heard this evening. Looks like it will be interesting to see how it works with/against MacApp. [Very quick first impression: existing code will convert smoothly, but not without some human intervention. Converting existing programs to O.O. will probably require some planning and redesign.] Martin Minow minow%thundr.dec@decwrl.dec.com minow@thundr.enet.dec.com (maybe the same)
mnkonar@yaya.SRC.Honeywell.COM (Murat N. Konar) (08/11/89)
I read somewhere (MacTutor?) that TC may someday include support
for Objective-C syntax (more Smalltalkish). Anyone know anything
about this?
____________________________________________________________________
Have a day. :^|
Murat N. Konar Honeywell Systems & Research Center, Camden, MN
mnkonar@SRC.honeywell.com (internet) {umn-cs,ems,bthpyd}!srcsip!mnkonar(UUCP)siegel@endor.harvard.edu (Rich Siegel) (08/11/89)
In article <9878@phoenix.Princeton.EDU> bskendig@phoenix.Princeton.EDU (Brian Kendig) writes: >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 will not compile ALL C++ code, only a subset, which encompasses the core object-oriented extensions. (The extensions are analogous to Object Pascal.) >Is it compatible with projects constructed by earlier versions of THINK C Yes; one caveat, though - the standard libraries have been rewritten for ANSI conformance, and the organization and names of header files have been changed substantially. >And what are its assembler capabilities? Does it have a (good) in-line >assembler? A full 68K/68881 assembler is supported inline, and it allows transparent access to C symbols; it also incorporates some of the compiler's branch and label optimizations, and a few others. R. ~~~~~~~~~~~~~~~ Rich Siegel Staff Software Developer Symantec Corporation, Language Products Group Internet: siegel@endor.harvard.edu UUCP: ..harvard!endor!siegel "When it comes to my health, I think of my body as a temple - or at least a moderately well-managed Presbyterian youth center." - Emo Phillips ~~~~~~~~~~~~~~~
awd@dbase.UUCP (Alastair Dallas) (08/12/89)
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 <whew> 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/
amanda@intercon.uu.net (Amanda Walker) (08/15/89)
In article <194@dbase.UUCP>, awd@dbase.UUCP (Alastair Dallas) writes: > THINK C 4.0 is almost completely ANSI C conformant. The few differences are > not important--const and volatile are not supported, for instance, At the very least THINK C should parse these, even if it doesn't do anything with them. "Almost conformant" is an oxymoron. -- Amanda Walker InterCon Systems Corporation -- amanda@intercon.uu.net | ...!uunet!intercon!amanda
jpd00964@uxa.cso.uiuc.edu (08/15/89)
Most important, is NetHack 3.0 compilable under TC 4.0? Michael Rutman Softmed
jpd00964@uxa.cso.uiuc.edu (08/16/89)
[parsing const] You could always just include the line #define const then it gets pre-processed out. Michael Rutman
pnm@goanna.oz (Paul BIG EARS Menon) (08/26/89)
awd@dbase.UUCP (Alastair Dallas) writes: ... >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 <whew> we don't have to use it--we'll wait for _true_ >C++ compatibility. Yes, I plead guilty to the above in a way. On receiving the upgrade to LightSpeed (or ThinkSpeed) Pascal with object support but without full documentation (for object use, ie) or classes, I wanted to 'hang out' till it arrived. It's funny how many excuses we make about our tools - good thing we aren't carpenters, huh? Think Pascal is a briliant package in its own right, and that's without a class library. I have never written a substantial program in C or any of its variants, I have always wanted to 'read' my programs, thus my bias towards Pascal. C++ wasn't sufficient to change my mind - personally, it looks even more like a spider's night out after walking through spilt ink. The only thing that would sway me is a class library, a decent one at that. Why not use MacApp? IMHO, MPW is no comparison to the Think environment. Wait for MacApp support from Think? I am sure it will arrive, but since Rich Siegel is stonewalling on when this will occur (can't blame him), I intend to use Think C 4.0. I am sacrificing the superior Pascal debugging environment, especially the "groucho" mode - very useful for objects, but in return, Think C's library should make up for it. I may even port my programs to LSP later on. Give credit where it's due, Think Pascal and C are great packages, there will always be the odd bug or two, or a wish for some extra feature(s). Think C may not be close enough to C++, but "I" couldn't care less. As was once said, "this too shall pass". Paul Menon, [Happy Little Vegemite] Dept of Computer Science, Royal Melbourne Institute of Technology, 124 Latrobe Street, Melbourne 3001, Victoria, Australia. PH: +61 3 660 3209 CSNET: pnm@goanna.rmit.oz BITNET/ARPA: pnm%goanna.rmit.oz@uunet.uu.net UUCP: ...!uunet!munnari!goanna.rmit.oz!pnm
svc@well.UUCP (Leonard Rosenthol) (08/28/89)
In article <2299@goanna.oz> pnm@goanna.oz (Paul BIG EARS Menon) writes: >awd@dbase.UUCP (Alastair Dallas) writes: >... > Yes, I plead guilty to the above in a way. On receiving the upgrade >to LightSpeed (or ThinkSpeed) Pascal with object support but without full >documentation (for object use, ie) or classes, I wanted to 'hang out' >till it arrived. It's funny how many excuses we make about our tools - good >thing we aren't carpenters, huh? Think Pascal is a briliant package in its >own right, and that's without a class library. > > Why not use MacApp? IMHO, MPW is no comparison to the Think environment. >Wait for MacApp support from Think? I am sure it will arrive, but since >Rich Siegel is stonewalling on when this will occur (can't blame him), I >intend to use Think C 4.0. > I agree with you that the support of Object Pascal in version 2.0 of Think Pascal was more of a tasty tidbit of the future than a completely workable environment as it came (this is NOT to say that what we got was not useful, just not as useful as it could be!). Symantec made the right decision with the class library and Think C 4.0 and rumor has it that the class library (or something similar) will come with the next version of Pascal. Also rumored is MacApp support that many are asking for. Between the cross compatible class library (since you can interuse Think C and Think Pascal code, including the object support) and the wonderful environments Symantec has a nice set of development environments. Will the TCLs outplay MacApp, could be, but only the future will tell. It might also be interesting to see some interaction of the two where my MacApp classes and TCL classes could be interchanged. Since Think Pascal uses Object Pascal which is what MacApp uses, it would seem quite possible for this to happen, but it would be REALLY neat... I would also like to see more propagation of TCL classes - MacApp has been around for a long time (back to the Lisa) but yet there have never been any PD/Shareware OR commercial classes made available. But the TCL just came out and already at least one company has announced commerical TCL classes - now for the PD/Shareware ones... -- +--------------------------------------------------+ Leonard Rosenthol | GEnie : MACgician Lazerware, inc. | MacNet: MACgician UUCP: svc@well.UUCP | ALink : D0025
ba0k+@andrew.cmu.edu (Brian Patrick Arnold) (08/29/89)
In Larry Rosenthol's message: > ...MacApp has been around for a long time (back to the Lisa) but yet > there have never been any PD/Shareware OR commercial classes made > available... There are MacApp object classes, an source code Browser DA, code fragments and even a parallel processing package already written for MacApp 2.0 available through MacAppDA: MacApp Developer's Association 4327 Rucker Avenue PO Box 23 Everett, WA 98206-0023 AppleLink: X0501 Object classes have been available for MacApp 1.1.1 since at least 1987. MacApp comes with ViewEdit, a graphical view/window/dialog resource editor, which was/is written in MacApp 2.0. I suspect when MacApp 2.0 is officially released (ViewEdit is still beta?), you will see more MacApp object classes available commercially. - Brian PS: I am only a member of MacAppDA, nobody paid me to post this.