c programming style - READ THIS

[Douglas J Freyburger]

> However, one would hope that the C community has stopped thinking in terms
> of the underlying bit patterns by now, and actually has a reasonable
> abstract model of what C programs do.  Unfortunately, I'm afraid that's not
> the case.  It may be that post-C programming languages will have to avoid
> defining the result of adding an integer to a pointer and various other C
> features that seem to cause a fair bit of confusion to some (such as array
> names standing for a constant pointer to the first element of the array).

[ Minor flame ]

I use C largely because it DOES allow (encourage?) me to
think in terms of the underlying bit patterns involved.  I
pay very close attention to just what is happening to
pointers when they are changed; that is the price I pay for
fast running programs.

When I am not concerned with performance, I often use a
different language that lets me play with the algorthym
without paying close attention to the actual machine
language generated, like PASCAL.  (Actually, after four
years full-time in C, I now just use a looser form of C
with simpler idioms, but it did take me thousands of lines
of C to get to that point.)  For just type-it-in-and-go
type programs where the engineer cost dominates, the
languages that are optimized for fast prototyping are
"better" anyways.

When I AM concerned with performance, I have to put in the
effort to track every pointer on my own, and all the other
neat stuff C lets me do without PASCAL or ForTran style
run-time checking.

Every language in its own place.  I place C in the high
performance but high programmer price category.