quinnt@turing.uucp (Tom Quinn x4-nnnn) (11/03/89)
I've been away from the net since the early summer, and missed any
discussion/reviews of Think C version 4.0. I'm still contemplating
whether to purchase the upgrade, and would like some input for my
decision. If anyone has some old articles around, or if someone could
take the time to summarize the discusisons that must have been held, I
would appreciate it if you could mail that information to me.
Please don't post to this newsgroup! I'm sure this is an old topic.
If anyone else would like me to forward to them anything I receive
contact me via e-mail and and I will send it along.
Thanks!
Tom
--
===========================================================================
Tom Quinn ||
Consultant at || uucp: {uunet!crdgw1|sun!sunbird}!gemed!quinnt
G.E. Medical Systems || internet: quinnt@gemed.ge.com
Milwaukee, WI 53201-414 ||
===========================================================================awd@dbase.UUCP (Alastair Dallas) (11/09/89)
In article <1346@mrsvr.UUCP>, quinnt@turing.uucp (Tom Quinn x4-nnnn) writes: > Please don't post to this newsgroup! I'm sure this is an old topic. > If anyone else would like me to forward to them anything I receive > contact me via e-mail and and I will send it along. Ah, but I wanted to post to the newsgroup; you just gave me an excuse. > I've been away from the net since the early summer, and missed any > discussion/reviews of Think C version 4.0. I'm still contemplating > whether to purchase the upgrade, and would like some input for my > decision. If anyone has some old articles around, or if someone could > take the time to summarize the discusisons that must have been held, I > would appreciate it if you could mail that information to me. There hasn't been that much discussion, as far as I'm concerned. I'm very enthusiastic about this product--I rushed an article to MacTutor (Oct '89) to describe it. This week, however, is the first chance I've had to really play with it. I wanted to post because I discovered a slight error in my article. TC is basically Think C 3.0 with a few object-oriented extensions and more ANSI-compatibility. These changes are not earth-shaking, really. What is exciting is the Think Class Library which is built on top of the compiler changes. TCL is a MacApp alternative, and since the compiler changes were done by Kahl, et. al., the environment is tight--things are relatively small and fast compared to a brute-force o-o implementation. (Obviously, I'm being subjective here.) TC 4.0 comes with Art Class, a MacPaint-type program demonstrating tear-off pallettes and all kinds of stuff. Art Class makes it clear that it is possible to write commercial-quality applications using TCL. And since it comes with full source code, you've got a leg up. Luckily, Rich Siegel of Think and Gregory Dow himself (author of TCL and Art Class) are available in this newsgroup. We've had some discussion (scanf() has a known bug--.01 becomes .1; the new multi-finder doesn't let Art Class update your cursor under some circumstances), but my impression is that a bunch of us are still climbing the learning curve. My bug: In the example in my MacTutor article I override CWindow::Close in order to make clicking in the close box equivalent to the Quit command. This is the only reason I create a subclass of CWindow. What I discovered after RTFM more closely is that overriding CWindow is rarely necessary. In this case, the standard CWindow::Close calls its supervisor (in my case, a Director) with CDirector::CloseWind. Since Directors are abstract classes, you have to override them, anyway, so you might as well respond to CloseWind with gApplication->Quit(). [I hope I got the names right--I left the manual home.] I would reccommend Think C 4.0 to my mother (except that she's stuck on APL). Apple says you gotta know o-o programming to survive in the Mac world, and I believe them. Then it's a choice between MacApp, which is >$500 if you don't already have MPW, some offbeat development system (Neon?), or Think C 4.0. TC is a relatively cheap introduction to the world of o-o, and you can be sure it will be supported for the foreseeable future. Hope that answers your question. /alastair/
jchiu@se-sd.NCR.COM (Jeff Chiu) (11/10/89)
How about a comparison between TCL and MacApp: E.g. the structure of their core classes - the basic building blocks of Mac applications, how similar are the two models? Having played TCL a bit, I feel that it's not too hard to find my way around the classes; but, does MacApp have a even simpler model? My only impression with MacApp was from a book at the bookstore, which seemed to show a simplier diagram? Comments from people experienced with both or from Symantec people would be very interesting. Other interesting comparisons: How about C++ feature list? MPW is a full implementation of c++, isn't it? But, what c++ features have actually been used in the MPW libraries distributed? Any comment about future plan from Symantec? How about developing enviroment? MPW C++ very slow, right? TC lacking "Makefile" is more annoying than before now that we have a lot of single-class files to deal with. An improvment for project management is in order. Which has better debugging environment? Let's shake some light but with as little heat as possible. -- jeff.chiu@sandiego.ncr.com jchiu@se-sd.sandiego.ncr.com (uunet or att)!ncrlnk!ncr-sd!se-sd!jchiu ucsd!se-sd!jchiu
drc@claris.com (Dennis Cohen) (11/10/89)
Okay. One of my few peeves with the THINK environments seems to be starting to strike more people now -- that is the project management. When working with something like TCL (maybe someday we'll get MacApp or something more sophisticated and larger) you have a lot of files that need to be compiled for virtually every project. Now, the simple (semi)solution is to build a library and include it which is fine; however, you now lose the ability to debug into it with the source debuggers. One of the few things that SADE did right from a user perspective is say that the debugging info is saved separately and that I can still use the .sym files in other projects (ThC terminology). What it boils down to is that something analogous to subprojects is necessary when dealing with libraries that are used in multiple development projects and the subprojects need to keep their attributes -- ie if I include the TCL project (which contains its object code and debugging info) in my Art Class project, when I debug the Art Class project I still have access to the sources and so forth from TCL. I know, it's a lot of work and could adversely affect performance (though the time it takes to recompile TCL in every project makes me disbelieve the latter), but I think it's something that is needed. Rich, would you please forward my comments along to Michael as a suggestion (and to John and David as well for THINK Pascal). I really think that it is a workable solution that would greatly benefit the customer base.
ewing@tramp.Colorado.EDU (EWING DAVID JAMES) (11/11/89)
In article <2127@se-sd.NCR.COM> jchiu@se-sd.SanDiego.NCR.COM (Jeff Chiu) writes: >How about a comparison between TCL and MacApp: > E.g. the structure of their core classes - the basic building blocks > of Mac applications, how similar are the two models? > > Having played TCL a bit, I feel that it's not too hard to find > my way around the classes; but, does MacApp have a even simpler > model? My only impression with MacApp was from a book at the > bookstore, which seemed to show a simplier diagram? Hmm. I will admit to not being a MacApp expert (or even intermediate user), but it certainly doesn't seem simpler than TCL. I have been using TCL for a couple of months, and I like it a lot. What ThinkC needs to add is a class browser. Actually, it would just need to make its Option-Double Click feature work for class methods. (Opt-Dbl Click does a search in the file in which the symbol clicked on is defined.) I am getting tired of doing multi-file searches of method names to see what's what. >Other interesting comparisons: > ... >MPW C++ very slow, right? In MPW's long tradition, I'm sure... :-) >TC lacking "Makefile" is more annoying than before now that we have >a lot of single-class files to deal with. An improvment for project >management is in order. What do you want it to do? I at least would like to see the ability add compile time definitions (#defines) like you can do on the command lines in MPW and Unix cc. I'd also like a source code control system like MPW's Projector (which I haven't had a chance to play with) or Unix's SCCS or RCS. (Of course, I would expect a nice, ThinkC - like, user interface.) >Which has better debugging environment? ThinkC! Although my experiences with SADE are very limited. (They're limited because I don't use MPW often because I don't like MPW very much. :=) Dave Ewing ewing@tramp.colorado.edu (128.138.238.33) ..!hplabs!boulder!onecom!tyvax!iftech!dave (My Mac IIx running uupc & MacOS!) AppleLink: D2408 (D2408@applelink.apple.com)
oster@dewey.soe.berkeley.edu (David Phillip Oster) (11/12/89)
Sheesh, you'd think programmers would at least read the manual once in awhile. The THINK C manual describes how to set up a group of projects that share source files so they each use the same copy. (It involves putting the project dependent code for the project "foo.proj" in a folder named "(foo.proj)".) When you start work on a new project that shares source code with an old one, use THINK C's Make Commmand, and it will check to se if any of the source files have been modified by some other program. Yes, it would be nice if you could configure THINK C to auto-run the Make when you open a new project, but since it is doing 99.99% of the job, you should cut it a little slack. ---peevishly yours, > The mac is a detour in the inevitable march of mediocre computers. > drs@bnlux0.bnl.gov (David R. Stampf) --- David Phillip Oster -master of the ad hoc odd hack. Arpa: oster@dewey.soe.berkeley.edu Uucp: {uwvax,decvax}!ucbvax!oster%dewey.soe.berkeley.edu
lsr@Apple.COM (Larry Rosenstein) (11/14/89)
In article <2127@se-sd.NCR.COM> jchiu@se-sd.SanDiego.NCR.COM (Jeff Chiu) writes: > my way around the classes; but, does MacApp have a even simpler > model? My only impression with MacApp was from a book at the > bookstore, which seemed to show a simplier diagram? That was probably Kurt Schmucker's book, which described a pre-release of MacApp 1.0. The latest version available is 2.0b9, and the class hierarchy is much richer. I suppose some might say richer is marketing-speak for more complicated, but in general, I don't think this is the case. MacApp 2.0 greatly simplified the task of laying out windows, and building custom dialog boxes. MacApp 2.0 also provides runtime access to the structure of your program. For example, you can find out all the subclasses of a given class at runtime, and you can create an instance of a class given its class name as a string. This makes it possible to implement a generalized object I/O mechanism. (I've done a simple version of this for an upcoming MacApp book.) >How about C++ feature list? MPW is a full implementation of c++, >isn't it? But, what c++ features have actually been used in the MPW >libraries distributed? Any comment about future plan from Symantec? MPW C++ is a full implementation of C++, with a couple of Macintosh extensions. -- Larry Rosenstein, Object Specialist Apple Computer, Inc. 20525 Mariani Ave, MS 77-A Cupertino, CA 95014 AppleLink:Rosenstein1 domain:lsr@Apple.COM UUCP:{sun,voder,nsc,decwrl}!apple!lsr
leipold@eplrx7.uucp (Walt Leipold) (11/14/89)
In article <296@dbase.UUCP> awd@dbase.UUCP (Alastair Dallas) writes: >Then it's a choice between MacApp, >which is >$500 if you don't already have MPW, some offbeat development >system (Neon?), or Think C 4.0. Yes, Neon is offbeat, but it generates fast, tight code. And for those who haven't got heavy iron, it runs just fine (even faster than Think C) on a Mac Plus. -- "As long as you've lit one candle, Walt Leipold you're allowed to curse the darkness." (leipolw%esvax@dupont.com) -- -- The UUCP Mailer