schanck@schooner.cis.ohio-state.edu (Christopher Schanck) (01/28/89)
Okay ladies and gents, pull up a chair, this may take awhile. Today, after all my mulling over whether or not to upgrade, I was passing through the OSU computer store and saw the 2.0 package (*not* the Professional one :-() was a mere $40. So okay, I bought it. I have since spent about 4 hours with it and have some impressions. First off, a word on upgrades. A couple people have stated that they were irritated that <insert your pet change here> was not documented as changed in the manuals. When I upgraded from 1.0 to 1.5, I *upgraded*, that is, I got the "Changes and Enhancements" book rather than the complete 1.5 docs. For the past several months I have been cursing having to refer to 3 manuals when I was unsure where things were, but today it was just the opposite. Since I bought 2.0 outright, the writers obviously felt they didn't need to detail all the changes, as they did/do in an update addition. Ideally I would like to have both the "changes" booklet and the full docs, but what can I say :-)! A word on the docs; they are much improved, particularly the Reference manual. There are headers on every page, and the cross references have been enhanced. For instance gives a good spot of info about it, instead of "see ...printf". This is a welcome addition. Minor Gripe: The manuals and such are yellow now; I prefer the old blue scheme! The integrated is certainly capable, basically as capable as 1.5 with the debugging options added. The debuggin is impressive for a small as the environment is; I can't wait to lay my hands on the standalone version. The screen handling by the editor is the same (boo-hiss) and the editor still has no windowing/multiple file capability. Oh well. I tested the make/tcc combo against the 1.5 versions as far as compile/link times were considered. Over a variety of files, with applications ranging in size from 10k-140k, I got a speedup improvement of ~15%. Pretty signifigant on my V20 4.77Mhz system! One drawback came for execution sizes. All the object files compiled with 2.0 were bigger than their 1.5 counterparts, even though I used the -v- option. Not by a whole lot, but they were bigger. Sigh. I haven't checked if there is a seperated "include debugging info" switch for the linker, but I think that is a far reach.... On the upside, from a completely subjective standpoint, the applications all seem zippier. Escpecially the couple I have which are string routine intensive. In the manual it states "increased speed of memory allocation and string routines". My VERY informal testing would seem to bear this out.... The issue of the copyright notice is moot as far as I am concerned; Borland wants EITHER you to copyright any software written with TC, or you have to insert their copyright notice in. That si just sound logic to protect their library routines. (you watch, I'll draw more discussion on this point than any other, go figure...) But I have saved the best for last. In 2.0, Borland has given us a real treat and a timesaver. I almost *overlooked* THELP. This is one hell of a memory resident program. Installed, it takes up about 8k. This 8k is the front for accessing a 200k+ file with oodles of good stuff, most importantly to my mind being a short description of each and every library function and reserved word! Neato! Never have to look up the order of arguments again. In my very humble opinion, this is worth $40 easily, and is justification for buying it if you are at all interested in C. It is geared toward the integrated environment, having editor commands and such, but it is neato. So overall, I give it a resounding thumbs-up. Buy it. If for THELP if nothing else. Feel free to respond/flame/complement etc here or by e-mail. Until version 2.5.... Chris -=- "I do not THINK in regular expressions, and I am not NP-complete!" --- Christopher Schanck, occasional human being. schanck@.cis.ohio-state.edu
Ralf.Brown@B.GP.CS.CMU.EDU (01/28/89)
In article <32857@tut.cis.ohio-state.edu>, schanck@schooner.cis.ohio-state.edu (Christopher Schanck) writes: }One drawback came for execution sizes. All the object files compiled }with 2.0 were bigger than their 1.5 counterparts, even though I used }the -v- option. Not by a whole lot, but they were bigger. Sigh. I What nobody seems to have thought of is the the *runtime*library* is larger, due to increased functionality. 1.5 executables are larger than 1.0 executables, for the same reason. The .COM for the null program ( main(){} ) grew from 1100-odd bytes in 1.0 to 1726 bytes in 2.0. }haven't checked if there is a seperated "include debugging info" }switch for the linker, but I think that is a far reach.... There is in fact such a switch, which TCC passes to the linker when invoked with -v. }[THELP] is geared toward the integrated environment, }having editor commands and such, but it is neato. No wonder, it uses the same help file that the integrated environment uses. -- UUCP: {ucbvax,harvard}!cs.cmu.edu!ralf -=-=-=- Voice: (412) 268-3053 (school) ARPA: ralf@cs.cmu.edu BIT: ralf%cs.cmu.edu@CMUCCVMA FIDO: Ralf Brown 1:129/31 Disclaimer? I claimed something? You cannot achieve the impossible without attempting the absurd.
wacey@paul.rutgers.edu ( ) (01/31/89)
When I first used 2.0 I noticed that my programs where about 1% larger than under 1.5. This was without debugging info. I then checked the code generated and discovered that Borland has made a Standard Stack Frame the default. In 1.5 they it wasn't, which resulted in smaller EXEs. So that get back the space all you have to do is turn off the stack frame option. But then you want be able to track back through the stack in the debugger. Iain Wacey
mdfreed@ziebmef.uucp (Mark Freedman) (02/03/89)
(larger Turbo C 2.0 object files)
Turbo C 2.0 incorporates dependancy information into the object file.
I don't believe that this can be defeated with the current release.
In my experience, the EXE files are about the same size as for 1.5
once the debugging information is removed (by recompiling with the proper
options, or by running TDSTRIP, which comes with the "Professional" package).
According to Al Stevens' "C Programming" column in Dr. Dobbs' Journal
(January 1989), TLIB has an undocumented switch (/0) which removes this
information from library modules. He also mentions that Borland will be
posting a utility to strip the extra information from OBJ files, and that
the next release will incorporate "no dependancy information" as an option.