Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!cica!iuvax!purdue!decwrl!shlump.nac.dec.com!mountn.dec.com!minow From: minow@mountn.dec.com (Martin Minow) Newsgroups: comp.sys.mac.programmer Subject: Re: Questions about THINK C v4.0 Message-ID: <569@mountn.dec.com> Date: 10 Aug 89 15:38:03 GMT References: <9878@phoenix.Princeton.EDU> Reply-To: minow%thundr.dec@decwrl.dec.com (Martin Minow) Organization: Digital Equipment Corporation Lines: 142 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(): #includemain(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)