Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!mintaka!spdcc!ima!haddock!karl
From: karl@haddock.ima.isc.com (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: a style question
Message-ID: <18367@haddock.ima.isc.com>
Date: 2 Oct 90 02:50:09 GMT
References: <7341@darkstar.ucsc.edu> <8660@ncar.ucar.edu> <1990Sep30.194448@IASTATE.EDU>
Reply-To: karl@kelp.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Cambridge, MA 02138-5302
Lines: 24

In article <1990Sep30.194448@IASTATE.EDU> john@IASTATE.EDU (Hascall John Paul) writes:
>[Re ++x vs x++] I find myself using ++x (which in my mind I attribute to some
>long gone, brain-damaged optimizer from my past -- but I still persist).

I also prefer ++x, not because it's more efficient but because it's the
conceptually simpler of the two: ++x is by definition x=x+1, while x++ is
defined as (temp=x, x=x+1, temp).  (Of course the arguments are the same:
the reason for suspecting it *might* be less efficient is because it has
the more complex semantics in the general case.)  So ++x wins under the rule
of "use the least powerful tool that does the job".  (Btw, this is the same
rule that makes GOTO a bad idea in most circumstances.)

>My `favorite' is:  --x;  and  x++;  (pre-decrement, post-increment!!!)

That's the other side of the coin.  Many algorithms turn out to be simpler
when described in terms of half-open intervals like [0,N).  Stepping through
such an interval is best done with post-decrement (*p++ or a[i++]) and
pre-decrement (*--p or a[--i]), and it's reasonable to use this convention
even when the value isn't being used (e.g. "if (*p == '-') p++", where the
"p++" is conceptually "(void)*p++").

The important point: it's not worth fighting over.

Karl W. Z. Heuer (karl@kelp.ima.isc.com or ima!kelp!karl), The Walking Lint