Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: henry@utzoo.UUCP (Henry Spencer)
Newsgroups: net.lang.c
Subject: Re: Uses of "short" ?
Message-ID: <6049@utzoo.UUCP>
Date: Sat, 12-Oct-85 20:24:21 EDT
Article-I.D.: utzoo.6049
Posted: Sat Oct 12 20:24:21 1985
Date-Received: Sat, 12-Oct-85 20:24:21 EDT
References: <486@houxh.UUCP>, <2600017@ccvaxa>
Organization: U of Toronto Zoology
Lines: 26

> I have no objection to the principle that we should try, other things
> being equal, to write portable code.  But the FIRST consideration of
> good professional practice is to write code that is clear,
> maintainable, and efficient in the environment for which we are paid
> to produce it.  It is not bad practice to put that environment first.

It must be nice to be so confident that your environment will never,
ever, ever, change radically.  Situations where such confidence is
justified are rare; perhaps your situation is such, but this is unusual.
One major advantage of Unix is that it does *not* tie you to any single
environment... but that advantage is wasted if your own code does.  We
may be especially conscious of this because our environment is scheduled
to change radically sometime in the next year or so, but the principle
is valid in general:  making your code machine-dependent limits its
lifetime.  This is sometimes appropriate... but only sometimes.  Less
often than most people think.

With certain specific exceptions (e.g. device drivers, the insides of hot
RasterOp implementations, the insides of strcpy(), etc.), portable C code
is portably efficient as well.  Clarity and maintainability are fairly
orthogonal to portability; if anything, there is a positive correlation,
because machine-dependent microsecond-grubbing tends to be unclear and
hard to maintain too.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry