Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!vrdxhq!bms-at!stuart
From: stuart@bms-at.UUCP (Stuart D. Gathman)
Newsgroups: comp.lang.c
Subject: Re: C vs assembler, or, Here We Go Again
Message-ID: <382@bms-at.UUCP>
Date: Fri, 24-Apr-87 13:50:25 EST
Article-I.D.: bms-at.382
Posted: Fri Apr 24 13:50:25 1987
Date-Received: Sat, 25-Apr-87 23:39:57 EST
References: <213@pyuxe.UUCP> <636@edge.UUCP> <1316@frog.UUCP> <658@edge.UUCP> <6361@mimsy.UUCP>
Organization: Business Management Systems, Inc., Fairfax, VA
Lines: 31
Summary: Why I program in 'C'.


While I have posted articles defending well written (macro) assembler
code as being just as compact and readable as 'C', I would now like to
explain the many advantages that 'C' provides over assembler.

1)	portability.  (Need I say more?)

2)	type checking.  I can make lots of nifty macros to handle specific
	data types, but the assembler could care less if I use DD (divide
	doubleword) on a word operand.

3)	scope rules.  In 'C' I can put in a block of code with its own
	variables guarranteed not to conflict with the rest of the program.
	With assembler, only seperately compiled modules provide private
	variables.

4)	expression syntax, especially pointer expressions.  Nothing beats
	p->b.t->x instead of sequences of move statements.  To be fair,
	I end up using lots of pointer variables in assembler for intermediate
	pointer results which tends to optimize the code as well as make it
	more readable.  Nevertheless . . .

Despite this, our people can still turn out a full featured  data
entry  program using assembler in only 15 minutes as opposed to 2
hrs for 'C'.  The difference is that  our  'C'  library  has  not
evolved  to  the  extent  that  the  assembler  library has.  (An
assembler data entry program consists of some  table  definitions
via macros and some subroutine hooks to implement deviations from
standard features.)
-- 
Stuart D. Gathman	<..!seismo!dgis!bms-at!stuart>