I'm afraid the example doesn't compile on anything I tested it with, because the compiler sees you trying to copy an integer object to a pointer object in the first case, and an integer literal to a pointer object in the second case.

Unlike C++ references, pointers do not merely alias another object - They are objects themselves, with their own data type, and they occupy a location in memory. They can mimic references by storing a data value which represents an address in memory (Hopefully an address of another valid object belonging to your program).

But they are far more versatile than references, (hence why pointer syntax is more complicated than that of a reference too), and because you can do some pretty unsafe stuff with pointers, the compiler is trained to check when you're about to do something extremely bad.

Here was the first line that MSVC 2003 choked on
this was the message it gave me In simple terms, the variable 'p' is a pointer variable, storing address data. variable 'a' is an int variable, storing int data.

The '=' operator (assignment operator) attempts to copy some int data (the integer 1) into a memory location designated for address data. The two types are generally incompatible, and the compiler rightly flags up an error.

Suppose for a moment that the compiler allowed you to do this, your int data was integer 1 and you later attempted to access a memory location represented by 1 (0x00000001), you're almost certainly going to be trying to look into a memory location which doesn't belong to your program.. What happens next is anyones guess! but you're most likely to crash'n'burn.

There are ways around doing this, you can use a reinterpret_cast to assign an integral value to a pointer object, but you're dicing with death if you do this - most OS's will just throw up a segfault or some other nastie if you actually try dereferencing a pointer when the memory address doesn't belong to your program - the standard, naturally, leaves its behaviour undefined.
This is an ugly, "hack". Remember I said that pointers can do some unsafe stuff - The reinterpret_cast is one of the gateways which allows you to do that nasty, unsafe stuff. IMHO its one of the most evil constructs available in C++.
- Luckilly, it sticks out in your code like a sore thumb - so if you do use it, and you do start getting random crashes or weird behaviour, you can bet good money that reinterpret_cast is part of the code which is doing something horribly unexpected. (You can use a 'C' style cast too, which will do the same thing, but is even more "evil" because it hides itself away in your code rather nefariously)




The next major error is this line Which is the same as the first error, although I think you intended to do something completely different than before.
Again, my compiler choked on the attempt to assign an integer data value of 3 to a memory location designated as an address value. But this time your intention seems to be to access the variable 'a'


In order to access an object referred-by (or pointed-by) a pointer variable, you need to explicitly de-reference that pointer variable.
In other words, your pointer is like a placeholder variable for the object (It remembers where the object is). You want to shove the pointer out the way, and gain direct access to the object.- You could think of a de-referencing operation like de-pointer-izing - the operation which grants access to the interested object.


The de-reference operator is the asterisk symbol, same as that used in pointer declarations. In order to do what you intended, the line needs to change to look like this

What you're describing here is true of C++ references, but not for pointers.

Here's a program which exhibits the behaviour you're describing

__________________

---