Path: utzoo!utgpu!watmath!att!tut.cis.ohio-state.edu!cica!ctrsol!ginosko!uunet!husc6!ogccse!blake!uw-beaver!fluke!mce
From: mce@tc.fluke.COM (Brian McElhinney)
Newsgroups: comp.sys.mac.programmer
Subject: Comments on THINK C 4.0
Message-ID: <10362@fluke.COM>
Date: 14 Aug 89 20:42:59 GMT
Sender: news@tc.fluke.COM
Organization: John Fluke Mfg. Co., Inc., Everett, WA
Lines: 51

Some quick initial comments:

	1) The "THINK Class Library" looks great, but it is very large.  So
	   large that it obviously needs a browser; they must have decided it
	   was too much work for this release?  Grrr.  The hard part is
	   knowing which files to parse, and parsing them.  When you have
	   access to the THINK C sources the rest should be relatively easy.
	   It would have been a better example than a MacPaint-clone (but then
	   so would a MacDraw-clone -- how do you save and restore objects to
	   disk?  Lists of objects?).

	2) The new() operator does no type checking.  You would like for

		CMyApplication gMyApplication;
		...
		gMyApplication = new(CApplication);

	   to cause a compiler error, but it doesn't (this type of error can
	   be a good way to crash your machine).  It's obvious that it would
	   be non-trivial to catch, but shows a distinct advantage for C++
	   constructors (where you can't get this wrong; you also can't forget
	   to call the initialization method, as the above does).

	3) The Sample and Pedestal applications: both contain Draw() and
	   DoClick() routines with comments saying "put your code here".  That
	   works fine for Draw(), but DoClick() ends up in CView, as if it were
	   not overloaded.  I must be missing something obvious.  HELP!!

	4) It's deceptive to call it a C++ subset; the list of C++ features
	   not implemented encompasses nearly the entire C++ language!  It
	   does not have operator overloading, references, constructors,
	   destructors, private data, friends, inlines, or, of course, all
	   the version 2.0 features (multiple inheritance, etc).

	   Actually, you could say that the philosophy behind C++ is opposed
	   to that of the Macintosh.  Stroustrup has said that "features that
	   would incur run-time or memory overheads even when not used were
	   avoided".  Objects in handles are an obvious need for Macintosh
	   programs, and just as obviously heretical to the rest of the C++
	   community.

	5) It may not be C++, but it is very well matched to the needs of the
	   Macintosh programming community.  The object-oriented features
	   coupled with the THINK Class Library should be a wonderful
	   environment for developing Macintosh applications.

	6) Except for the lack of a &%*$# browser...
 
 
Brian McElhinney
mce@tc.fluke.com