Path: utzoo!mnetor!uunet!husc6!bloom-beacon!athena.mit.edu!tada
From: tada@athena.mit.edu (Michael Zehr)
Newsgroups: comp.lang.c
Subject: Re: I forget what it was originally called.
Message-ID: <3623@bloom-beacon.MIT.EDU>
Date: 10 Mar 88 17:47:00 GMT
References: <3505@bloom-beacon.MIT.EDU> <3850010@hpfclq.HP.COM>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: tada@athena.mit.edu (Michael Zehr)
Organization: Massachusetts Institute of Technology
Lines: 78
Summary: reply. new question about compilers.

In article <3850010@hpfclq.HP.COM> mike@hpfclq.HP.COM (Mike McNelly) writes:
> [commenting on "array[i] = array[i++]" style code:]
> Frankly I have little sympathy with anyone writing code in this manner.
> It's cute but it's also no more efficient than alternatives that do what
> you really wanted to do in a much less ambiguous fashion.  If you
> inherited this code you have my condolences.
>
>Mike McNelly

(start minor flame) You're right.  I have no sympathy for myself
either, and I hope I never make that mistake again.  One of the
reasons why I read this newsgroup is because I'm a fledgling C
programmer.  (I've taken no courses using the language, and I've only
been programming for about 1/2 year.  Also, so far the programs I've
written are of a nature that I'm far more concerned about speed than
maintainability.)  Until I discover for myself what's most efficient,
and what works and what doesn't, I'm going to make mistakes.  But if I
ask a more experienced person for help, I'd rather be given advice
than be told I'm doing something wrong.  (end minor flame)

Which brings me to another question:  How good are compilers these
day?  Can they optimize just as well as a programmer (without
resorting to assembly, that is) or not?  For example:

A)

temp = {expression}
a[temp] = 1;
b[temp] = 2;
c[temp] = 3;

B)

a[temp={expression}]=1;
b[temp]=2;
c[temp]=3;


C)

a[{expression}]=1;
b[{expression}]=2;
c[{expression}]=3;


A) is very readable.  B) may or may not be slightly faster.  Does
anyone know whether B) is typically faster than A)?  Would it probably
generate the same code?  C) is slower since {expression} is evaluated
three times, *unless* the compiler knows to evaluate it once and put
it in a register.  Which may be about the same thing as what A) and B)
are doing, *except* in A) and B) it might will write the value into a
variable, which is slower than storing it in a register.  Of course,
there's always:

D)

{
register temp;
temp = {expression};
.
.
.
}

But I find this harder to read, and furthermore, since C compilers can
ignore register declarations anyway, it might put it in as a normal
variable (just like A) ), but it will slow down because it's allocated
each time through the block of code.

So -- other than not having any sympathy for me becuase I don't
already know the answer :-)  does anyone have any comments?



  
-------
michael j zehr
"My opinions are my own ... as is my spelling."