[comp.sys.ibm.pc] Turbo C vs. Pascal

mwh1629@uxf.cso.uiuc.edu (03/06/89)

     I have been fiddling with Turbo Pascal and Turbo C, trying to decide
which is best.  My primary concern is the final EXE file size.  C seems
to compile huge.  A program to print "Hello, world." on the screen 
compiled to 9k, while a program to print out a table of numbers and sort
them in Turbo Pascal only took 6k.  A simple Mandelbrot program in Turbo C was 
24k.  Does the size of the C code stop increasing after a certain point
(i.e. a long C program is of equal length to a long Pascal program) or are C
files generally very large?  I'm not overly-concerned with small differences
in size, but it seems to me that if it takes 9k to print something on the
screen, a decent sized C program will fill up my hard drive.

     I also have two general questions. If you compile a program with a language
and then commercially release it are you required to pay some money to the
compiler's maker?  Lastly, what's the deal with version numbers?  I think I
was told that, for example, Version 2.34 means that 4 is a bug fix, 3 is a
minor improvement and 2 is a major change.  Is this correct?

                    Thanks,
                    Matt Henry
"[College is] the most profitable damn nap I ever took." - Cecil Adams.

spolsky-joel@CS.YALE.EDU (Joel Spolsky) (03/07/89)

In article <46500039@uxf.cso.uiuc.edu> mwh1629@uxf.cso.uiuc.edu writes:
| 
|      I have been fiddling with Turbo Pascal and Turbo C, trying to decide
| which is best.  My primary concern is the final EXE file size.  C seems
| to compile huge.  A program to print "Hello, world." on the screen 
| compiled to 9k, while a program to print out a table of numbers and sort
| them in Turbo Pascal only took 6k.  A simple Mandelbrot program in Turbo C was 
| 24k.  Does the size of the C code stop increasing after a certain point
| (i.e. a long C program is of equal length to a long Pascal program) or are C
| files generally very large?  I'm not overly-concerned with small differences
| in size, but it seems to me that if it takes 9k to print something on the
| screen, a decent sized C program will fill up my hard drive.

Most of that 9K is overhead for including the function printf() which
is quite complicated. Needless to say this is a one shot deal. Also,
you probably didn't turn off debugging information, which would
further reduce the size of the .exe file. Finally, you could convert
EXE files to COM files if they are smaller than 64K (text + data)
which makes them even smaller, usually. In other words, you can expect
that for normal size programs Turbo-C and Turbo-Pascal will produce
about the same size code, however C source is smaller, requires less
typing; also C allows you to express some things in less code than it
would take to express them in Pascal (e.g. strings > 255 characters,
unions, bitfields, etc).

| 
|      I also have two general questions. If you compile a program with a language
| and then commercially release it are you required to pay some money to the
| compiler's maker?  

Hypothetically the compile maker can require a royalty, but Borland
doesn't. 

| Lastly, what's the deal with version numbers?  I think I
| was told that, for example, Version 2.34 means that 4 is a bug fix, 3 is a
| minor improvement and 2 is a major change.  Is this correct?

No hard and fast rules. The rule I like is that changing the integer
means a major rewrite, the .1 reflects new features, the .01 is
anything that is usually transparent to the user (bug fixes or
speedups). 

|                     Matt Henry

+----------------+----------------------------------------------------------+
|  Joel Spolsky  | bitnet: spolsky@yalecs.bitnet     uucp: ...!yale!spolsky |
|                | internet: spolsky@cs.yale.edu     voicenet: 203-436-1483 |
+----------------+----------------------------------------------------------+
                                                      #include <disclaimer.h>

hollombe@ttidca.TTI.COM (The Polymath) (03/08/89)

In article <46500039@uxf.cso.uiuc.edu> mwh1629@uxf.cso.uiuc.edu writes:
}... C seems
}to compile huge.  A program to print "Hello, world." on the screen 
}compiled to 9k, while a program to print out a table of numbers and sort
}them in Turbo Pascal only took 6k.  ...

Have you tried turning off all the debug hooks and bounds checking Turbo-C
puts in by default?  That will usually shrink a program considerably.
Also, the printf() family in C includes some very powerful formatting
capabilities that require significant code to implement.  A simple putch()
loop is all you need for "Hello world.".

}     I also have two general questions. If you compile a program with a language
}and then commercially release it are you required to pay some money to the
}compiler's maker?

Depends on the licensing agreement.  Borland is quite reasonable about
this.  Their only requirement is that your code include a copyright
declaration.  Yours or theirs, it doesn't matter, but your code must be
copyrighted.

}Lastly, what's the deal with version numbers?  I think I
}was told that, for example, Version 2.34 means that 4 is a bug fix, 3 is a
}minor improvement and 2 is a major change.  Is this correct?

This probably varies by manufacturer.  Major vs. minor vs. bug fix are
rather subjective, anyway.  Ask and they might tell you, but don't expect
anyone to call a bug fix a bug fix. (-:

-- 
The Polymath (aka: Jerry Hollombe, hollombe@ttidca.tti.com)  Illegitimati Nil
Citicorp(+)TTI                                                 Carborundum
3100 Ocean Park Blvd.   (213) 452-9191, x2483
Santa Monica, CA  90405 {csun|philabs|psivax}!ttidca!hollombe

keithe@tekgvs.LABS.TEK.COM (Keith Ericson) (03/09/89)

In article <52903@yale-celray.yale.UUCP> spolsky-joel@CS.YALE.EDU (Joel Spolsky) writes:
<In article <46500039@uxf.cso.uiuc.edu> mwh1629@uxf.cso.uiuc.edu writes:
<| 
<| Lastly, what's the deal with version numbers?  I think I
<| was told that, for example, Version 2.34 means that 4 is a bug fix, 3 is a
<| minor improvement and 2 is a major change.  Is this correct?
<
<No hard and fast rules. The rule I like is that changing the integer
<means a major rewrite, the .1 reflects new features, the .01 is
<anything that is usually transparent to the user (bug fixes or
<speedups). 
<

Except for Microsoft: X.YZ where Y=0 means it's a Beta Release. Y >=2
means it's maybe OK, but you're safest to hold out for Y >=3. Z <> 0
means it's a minor tweak.  Also, there are extensions (e.g., MS-DOS 3.30A)
that No one understands...

kEITH (only joking) (maybe) eRICSON

Ralf.Brown@B.GP.CS.CMU.EDU (03/09/89)

In article <4006@ttidca.TTI.COM>, hollombe@ttidca.TTI.COM (The Polymath) writes:
}In article <46500039@uxf.cso.uiuc.edu> mwh1629@uxf.cso.uiuc.edu writes:
}}... C seems
}}to compile huge.  A program to print "Hello, world." on the screen 
}}compiled to 9k, while a program to print out a table of numbers and sort
}}them in Turbo Pascal only took 6k.  ...
}
}A simple putch()
}loop is all you need for "Hello world.".

Even simpler,

main()
{
     puts("Hello, world.") ;
}

}This probably varies by manufacturer.  Major vs. minor vs. bug fix are
}rather subjective, anyway.  Ask and they might tell you, but don't expect
}anyone to call a bug fix a bug fix. (-:

Yeah, Ashton-Tate is now calling them "anomalies"....  dBASE IV has lots of
"anomalies" that A-T will admit to, but no "bugs".
--
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.

shurr@cbnews.ATT.COM (Larry A. Shurr) (03/10/89)

In article <46500039@uxf.cso.uiuc.edu> mwh1629@uxf.cso.uiuc.edu writes:

>     I have been fiddling with Turbo Pascal and Turbo C, trying to decide
>which is best.  My primary concern is the final EXE file size.  C seems
>to compile huge.  A program to print "Hello, world." on the screen 
>compiled to 9k, while a program to print out a table of numbers and sort
>them in Turbo Pascal only took 6k.  A simple Mandelbrot program in Turbo C was 
>24k...

The integrated environment Turbo C likes to put extra debugging information
in the executable, apparently even if you tell it not to, though it may
simply be the case that I didn't set the right options.

What I found was that when I compiled the "Hello world!" program in the
integrated environment, the .exe file was 9489 bytes in length.  The
Mortice Kern Systems (MKS) strip utility (like Unix strip: removes 
debug information from the file - does not compress the file like 
Microsoft's EXEPACK utility) reduced it to 6752 bytes.  MKS size utility
showed the program size as 6240 bytes of text and 0 bss space.

Then I compiled using the command line compiler with no debug options set.
The resulting .exe file was 6544 bytes long.  The strip utility did not
reduce the size of the file and size indicated the program size as 6032
bytes of text and 208 bytes of bss for a total size of 6240 bytes.  (This
difference between the integrated and command line compilers is interest-
ing.  The two compilers allocate text and data differently, but otherwise
produce the same results.  Note: in both cases, I used small model.)

Thus, Turbo C is not as bad as it first appears.  I don't have your
other programs to try so I can't comment on them.  However, I will
test them in the same way if you send them to me.

>I also have two general questions. If you compile a program with a language
>and then commercially release it are you required to pay some money to the
>compiler's maker?  

This depends on your liscense agreement with the language vendor.  Once
upon a time, Microsoft (and others) required this in their liscenses.
In general, they have now abandoned this requirement.  Borland does not
require money though they now require you either to claim a copyright
for yourself and imbed a copyright notice in your compiled program or
give them the copyright (I think I remember that correctly (notice to 
the net.police: I do have my own, paid-for copies of Turbo Pascal 5.0 
and Turbo C 2.0 so leave me alone!)).

>                   Lastly, what's the deal with version numbers?  I think I
>was told that, for example, Version 2.34 means that 4 is a bug fix, 3 is a
>minor improvement and 2 is a major change.  Is this correct?

Your interpretation is logical, plausible, and is even true in some cases,
but this is similarly dependent on your vendor.

regards, Larry
-- 
Signed: Larry A. Shurr (att!cbnews!cbema!las or osu-cis!apr!las)
Clever signature, Wonderful wit, Outdo the others, Be a big hit! - Burma Shave
(With apologies to the real thing.  The above represents my views only.)