c programming style - READ THIS

[Guy Harris]

> 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.

But is this a case of "thinking of the underlying bit patterns", or is it a
case of thinking of the underlying operations on an abstract machine?  I.e.,
do you think of a pointer as a natural number indexing a large array which
is your process' address space (which may not work on a segmented machine!),
or do you think of it as something that points to an object?  You can still
think in the latter terms without forgetting the important part of how
pointers are implemented - i.e., I doubt the ability to cast pointers to
some integral type and back again is needed, in general, for efficiency

> 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.

What do you mean by "track every pointer on (your) own"?  True, you can't
use pointers in FORTRAN without run-time checking, but then you can't use
pointers in FORTRAN *with* run-time checking, since it doesn't *have*
pointers.  FORTRAN doesn't do much "run-time checking" because it doesn't
have much checking to do - no pointers, so no null-pointer checking; no
subrange or enumerated types, so no checking assignments to such types.  I
believe there are many PASCAL compilers that will allow you to turn the
checking off - of course, if you do so, you should have good reason to be
sure the errors that the checking would detect should occur, considering
that those errors can bomb your program regardless of whether it was written
in PASCAL or C.  (For instance, if you get a pointer from a routine which
could return a null pointer, *always* check it before using it unless you
*know* that the particular call to that routine which returns the pointer
won't return a null pointer.  And make *sure* you really "know" it.  Just
because you created a file "/tmp/foo" and made it readable doesn't mean
'fopen("/tmp/foo", "r")' is not going to return NULL - you could get an I/O
error, or somebody else could have unlinked the file while you weren't
looking, or...)


You don't have to think of pointers as integers indexing a large array which
is your address space (and think of null pointers as being the integer 0) in
order to write efficient C code.  (And if you do think that way, what you
may end up with is C code that will break when somebody else tries to run it
on their machine - which will force *them* to fix the problem.)

	Guy Harris