Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!endor!singer From: singer@endor.harvard.edu (THINK Technologies) Newsgroups: comp.sys.mac Subject: Re: C and large data model Message-ID: <3566@husc6.harvard.edu> Date: 16 Dec 87 14:31:48 GMT References: <8712152132.AA10832@decwrl.dec.com> Sender: news@husc6.harvard.edu Reply-To: singer@endor.UUCP (THINK Technologies) Organization: THINK Technologies, Bedford, MA Lines: 74 Rather than argue the merits of one versus the other (noticed that I started this, now I get to pay) I will simply respond to specific technical points... In article <8712152132.AA10832@decwrl.dec.com> vantreeck@curie.dec.com writes: >Aztec has had a VERY NICE symbolic debugger, db, for a long time. Aztec C >provides compiler and link options to also generate symbol tables that can be >used by other debuggers, e.g., MacsBug and Tmon. Manx is developing a source >line debugger, sdb. My apologies for that; I did mean to say "source level" debugger. Using TMON in conjunction with LightspeedC it is also possible to get symbolic debugging that resembles Aztec's. >Last time I checked, LightSpeed C required all source files in project to be in >one directory. Aztec's make does not have that limitation, e.g., I have sources When was the last time you checked? Every version since 2.01 has complete support for HFS, and that's largely automatic, so you don't need to specify pathnames for #include files, and you can add source and library files from *any* directory - or even another disk. >and database routines in yet another, etc. For larger development projects you >will probably have sources in multiple directories and have complicated >dependencies that an automated make, like LightSpeed's, can't handle. In that >case, you will no choice but to use a standard make facility. LightspeedC was written using itself. The sources are in multiple directories. It consists of over a hundred source files, plus various libraries and #includes. >With LightSpeed C you have to leave their environment to build non-C modules. >You don't have to leave the Aztec C shell when building non-C modules. >LightSpeed C makes no attempt to integrate non-Think products into it's >environment. Manx makes a good effort at having an open interface that lets you >integrate other tools into the environment. As an example, clicking on the >"Edit" item in the menu brings up my QUED editor instead of the default Aztec >editor, z (which is like vi). Granted that all of the above is true. But the integrated decision was made with speed in mind. How long does it take you to go from QUED to the compiler? On a hard disk, maybe not long. But in LightspeedC, the compiler is *right there*. >If you're more interested in quick prototyping than careful up-front >design (and you're only using C), then LightSpeed C will be particularly >appealing because of the quick turn-around time. LightspeedC is certainly appealing because of its quick turnaround, but I disagree with the assertion that it's only good for prototyping. After all some very popluar Macintosh programs (Aldus PageMaker, Adobe Illustrator, Quark XPress, Red Ryder, StuffIt, LightspeedC itself, and others) were written using LightspeedC. I would hesitate to call these "Quick Prototypes". >Aztec C and LightSpeed C are in the same ball park with respect compilation and >link times, code size, and run-time speed. Neither is too hot a code >optimization, e.g., neither does common subexpression elimantion, loop jamming, >dead code elimination, etc.. I hear Green Hill's C compiler that works with >Apple's MPW does an excellent job of optimization -- but does not support the >large data nor large code models. I hear the same. > >George Van Treeck >Digital Equipment Corporation (The home of industrial-strength software tools. --Rich **The opinions stated herein are my own opinions and do not necessarily represent the policies or opinions of my employer (THINK Technologies). * Richard M. Siegel | {decvax, ucbvax, sun}!harvard!endor!singer * * Customer Support | singer@endor.harvard.edu * * Symantec, THINK Technologies Division. (No snappy quote) *