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():
	#include 
	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)