[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Good documentation on c/c++ pointers?



[ Resending??? ]

On Tue, 2004-12-07 at 08:41, Kyle Pointer wrote:
> Hey, I'm working on C/C++ but my book is horrible.
> Would anyone be able to suggest some good documentation on the use of 
> pointers?

Pointers are the biggest "epiphany" a 2G or 3G programmer will ever
have.  I know, they were for me (I was 15).

We'll break this down bit-by-bit ...

1)  Variables store values

Integers store integers.
Floating points store floating point types.

Pointers are just another type of variable that stores a value.
Keep that in mind.

2)  Every variable has a memory address

[ NOTE:  Hard core guys -- this is a mega-oversimplification, I know. 
But don't bombard this guy just yet, okay? ;-]

Variables are not known to the computer by name.
They are known by the computer as an address.

The "compiler" just hides this from you.

When you create a variable "A", you know it as "A".
But the computer probably knows the variable as something like address
"0023:31A23C51".

So when the program accesses the value of A, it goes to that address.
It then retrieves the value.

3)  Pointers are variables that store addresses, not usable values.

So what is a pointer?  It's a variable that stores an address.
I other words, instead of holding the value, like another variable
would, a pointer variable holds a memory address.

That memory address could point to an area with a usable address.

Let's use an example:  

  int A;      // create a integer variable
  int *pA;    // create a pointer to an integer variable

  A = 7;              // assign 7
  printf("%d\n",A);   // prints 7

  pA = &A             // assign _address_ of A to pointer
  printf("%d\n",*pA)  // prints value at address _pointed_ at PA

  *pA = A             // assign value of A to address _pointed_ at by PA
  printf("%d\n",*pA)  // prints 7

  printf("%d\n",pA)   // prints address (e.g., 0023:31A23C51)
  [ NOTE:  this last command might require "(void *)&pA" to avoid
    syntax errors -- long story]

Why might we do this?  

Well, there are countless applications.  But largely so we can switch
the value a variable returns without changing any memory.

BTW, in case you're wondering, why did we use?  
  int *pA

A pointer is _not_ of type integer.  In reality, we _could_ use:
  void *pA

And get the _same_ results.  But why do we use int?  It's so if we
accidentally assign an integer pointer to an address that does not have
an integer, we don't get a mess.  Long story short, it's a 100%
_syntax_/_coder_ consideration, 0% computer.

To the C compiler, an address is an address.  In x86, both standard
32-bit/4GB and even PAE36/64MB (4-bit overhang) programming, 48-bit
segmented (16:32) addresses (virtually 256TB) are used.  It doesn't
matter if we are pointing at a char, integer, float, long, etc...  An
address is what we are actually storing in the variable location.

-- Bryan

BTW, in case you are curious, for x86-64 "Long" mode programming, we use
PAE52 partially segmented (4-bit overhang), even though it's only
48-bit.  The 48-bit is for compatibility with the i386 segmentation
16:32, which is implemented with support for the i486+ TLB (translation
lookahead buffer) with a massive compile-time improvement (hence why
most programs today are built "march=i486").  At the same time,
PAE36/64GB expects a "4-bit overhang" (long story, but it has to do with
how the last 12 bits of the 16 portion of 16:32 map into the 32 portion,
leaving 4 bits overhang -- hence how Intel gets 36-bit/64GB addressing,
PAE36, on a 32-bit/4GB processor).  The result is PAE52 -- 52-bit
programmer/register addressing.


-- 
Bryan J. Smith                                 b.j.smith@ieee.org 
------------------------------------------------------------------ 
Beware of advocates who justify their preference not in terms of
what they like about their "choice," but what they did not like
about another option.  Such advocacy is more hurtful than helpful.



-
To unsubscribe, send email to majordomo@silug.org with
"unsubscribe silug-discuss" in the body.