Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!bbn!papaya.bbn.com!rsalz
From: rsalz@bbn.com (Rich Salz)
Newsgroups: comp.lang.c
Subject: Optimization (was "another auto-increment problem")
Message-ID: <192@papaya.bbn.com>
Date: Sun, 27-Sep-87 11:05:27 EDT
Article-I.D.: papaya.192
Posted: Sun Sep 27 11:05:27 1987
Date-Received: Mon, 28-Sep-87 01:48:34 EDT
References: <3680001@wdl1.UUCP> <723@ima.ISC.COM>
Reply-To: rsalz@bbn.com (Rich Salz)
Organization: BBN Laboratories, Cambridge MA
Lines: 27

Warning!  Generalizations abound, nit-pickers beware (and go away :-)

Someone writes:
> ...
>	float junk[3], *junk_ptr;
> ...
>	junk_ptr = (float *) junk;
>	xfpt(*junk_ptr++, *junk_ptr++, *junk_ptr);
Everyone's jumped in about how this is broken code -- the order of
evaluation isn't defined.  My point is different:  isn't this code more
inefficient, anyhow?  On all machines where X is a compile-time constant,
&junk[X] is a compile-time constant.  That's often faster for limited
cases then going through a pointer indirection:  C compilers have to be
very conservative about the way they handle pointers and the things
they're pointed to.

In general, optimization tricks should only be done after the entire
program is working and stable.  Not to cast aspersions, but if this is the
first time the original poster has come across the evaluation-order
gotcha, then the code is not at that stage yet.  Remember Knuth:
"premature optimization is the root of all evil."

Interested parties should get a copy of "Writing Efficient Programs," by
Jon Bentley.  Prentice-Hall, ISBN 0-13-970244-X.
-- 
For comp.sources.unix stuff, mail to sources@uunet.uu.net.
And if C is the assembly language of the 80's, why is ACP written in MIX?