Sheldon Simms said:
For example, Roose said "a pointer is an integer". This is not
true. A pointer *might* be an integer, and it might be something
else, like two distinct integers, or something else entirely.
I understand that you might not see why it matters one way or
the other, but there is a good reason to be precisely correct
right from the start: it prevents you from making lazy assumptions
that might not bite you now, but that probably will bite you
later.
Indeed, I just posted elsewhere on this thread a concrete example of
code that failed on a certain platform precisely because a pointer is
*not* just an integer on that platform. (The platform was a Cray T90.
A byte pointer on that platform is a 64-bit word pointer with a byte
offset stored in the high-order 3 bits. The code tried to convert the
pointer to an integer and perform arithmetic on the integer
representation.)
On many (most?) current systems, pointers are actually implemented as
integers. If you examine a pointer with a debugger, or cast it to an
appropriate integer type and print its value, you'll see something
that looks like a numeric hardware address (actually a virtual address
in most cases). If you let this observation lead you to assume that
pointers are *always* just integers, you're likely to make mistakes
like the one I described. If, on the other hand, you think of a
pointer (or an address) as an abstraction that may or may not be
implemented as an integer, you'll have a better understanding of
what's really going on.
A pointer, as the name implies, points to something. How it does so
is usually not something you need to worry about (though knowing the
target-specific details can be useful when you're tracking down a
problem). If it points to an array, you can perform arithmetic on it
to point to other parts of the same array. If two pointers point to
two distinct objects, you can ask whether the pointers are equal, but
there's no much else you can safely do with them. All these things
are derived from the abstraction of what a pointer is as defined by
the C language; you won't get this from an assumption that a pointer
is an integer.
What I'm arguing is not that you shouldn't know the underlying
details; that knowledge can certainly be useful, and can lead to a
clearer understanding of why the abstractions are defined the way they
are. What I'm arguing is that you should avoid *depending* on the
underlying details. The programmer who made the mistake I mentioned
above did so because he assumed that the underlying details of one
platform applied everywhere; I was able to track down the problem
because I knew the underlying details of the platform on which the
code failed, and how to avoid depending on them.