C或c++指针与简单内存地址的另一个不同之处是，我在其他答案中没有看到不同的指针类型(尽管考虑到它们的总大小，我可能忽略了它)。但它可能是最重要的一个，因为即使是经验丰富的C/ c++程序员也会被它绊倒:

编译器可能会假设不兼容类型的指针不指向相同的地址，即使它们很明显指向相同的地址，这可能会导致简单的pointer==address模型不可能出现的行为。考虑以下代码(假设sizeof(int) = 2*sizeof(short)):

unsigned int i = 0;
unsigned short* p = (unsigned short*)&i;
p[0]=p[1]=1;

if (i == 2 + (unsigned short)(-1))
{
  // you'd expect this to execute, but it need not
}

if (i == 0)
{
  // you'd expect this not to execute, but it actually may do so
}

注意，char*有一个例外，所以使用char*操作值是可能的(尽管不是很可移植)。

以下是我过去是如何向一些困惑的人解释的: 指针有两个影响其行为的属性。它有一个值(在典型环境中)是一个内存地址，还有一个类型(告诉您它所指向的对象的类型和大小)。

例如，给定:

union {
    int i;
    char c;
} u;

你可以有三个不同的指针都指向同一个对象:

void *v = &u;
int *i = &u.i;
char *c = &u.c;

如果你比较这些指针的值，它们都是相等的:

v==i && i==c

但是，如果对每个指针加1，就会发现它们所指向的类型变得相关了。

i++;
c++;
// You can't perform arithmetic on a void pointer, so no v++
i != c

此时，变量i和c将具有不同的值，因为i++使i包含下一个可访问的整数的地址，而c++使c指向下一个可寻址的字符。通常，整数比字符占用更多的内存，所以在它们都加一之后，i的值将比c的值更大。

很难确切地说出这些书的作者到底是什么意思。指针是否包含地址取决于如何定义地址和如何定义指针。

从所有的回答来看，有些人认为(1)地址必须是整数，(2)指针不需要是虚的，因为规范中没有这么说。根据这些假设，显然指针不一定包含地址。

然而，我们看到，虽然(2)可能是真的，(1)可能不一定是真的。根据@ corn秸秆的答案，&被称为操作符的地址，这是怎么回事?这是否意味着规范的作者希望指针包含地址?

我们可以说，指针包含一个地址，但地址不一定是整数?也许吧。

我认为所有这些都是废话连篇的迂腐语义学。实际上，这是毫无价值的。你能想到一个编译器以这样的方式生成代码，指针的值不是一个地址吗?如果有，是什么?我也是这么想的……

我认为这本书的作者(第一个摘录声称指针不一定只是地址)可能指的是指针自带固有类型信息这一事实。

例如,

 int x;
 int* y = &x;
 char* z = &x;

y和z都是指针，但y+1和z+1是不同的。如果它们是内存地址，难道这些表达式不会给你相同的值吗?

在这里，把指针当作地址的想法通常会导致悲伤。之所以会出现bug，是因为人们将指针视为地址，而这通常会导致不幸。

55555可能不是指针，尽管它可能是一个地址，但(int*)55555是一个指针。55555+1 = 55556，但是(int*)55555+1是55559(在sizeof(int)方面的+/-差异)。

马克·贝西(Mark Bessey)已经说过了，但这一点需要再次强调，直到人们理解为止。

指针与变量的关系比与文字3的关系更大。

指针是一个值(地址)和类型(带有其他属性，如只读)的元组。类型(以及附加参数(如果有的话)可以进一步定义或限制上下文;如。__far ptr， __near ptr:地址的上下文是什么:堆栈，堆，线性地址，某处的偏移量，物理内存或其他。

正是type的属性使得指针算术与整数算术略有不同。

指针不是变量的反例太多了，不容忽视

fopen返回FILE指针。(变量在哪里) 堆栈指针或帧指针通常是不可寻址的寄存器 *(int *)0x1231330 = 13;——将任意整数值转换为pointer_of_integer类型，并在不引入变量的情况下写入/读取整数值

在c程序的生命周期中，会有许多其他没有地址的临时指针实例——因此它们不是变量，而是带有编译时相关类型的表达式/值。

指针是一个保存内存地址的变量，而不是地址本身。但是，您可以解除对指针的引用-并访问内存位置。

例如:

int q = 10; /*say q is at address 0x10203040*/
int *p = &q; /*means let p contain the address of q, which is 0x10203040*/
*p = 20; /*set whatever is at the address pointed by "p" as 20*/

就是这样。就是这么简单。

一个演示我所说内容的程序，其输出如下:

http://ideone.com/rcSUsb

程序:

#include <stdio.h>

int main(int argc, char *argv[])
{
  /* POINTER AS AN ADDRESS */
  int q = 10;
  int *p = &q;

  printf("address of q is %p\n", (void *)&q);
  printf("p contains %p\n", (void *)p);

  p = NULL;
  printf("NULL p now contains %p\n", (void *)p);
  return 0;
}

A pointer, like any other variable in C, is fundamentally a collection of bits which may be represented by one or more concatenated unsigned char values (as with any other type of cariable, sizeof(some_variable) will indicate the number of unsigned char values). What makes a pointer different from other variables is that a C compiler will interpret the bits in a pointer as identifying, somehow, a place where a variable may be stored. In C, unlike some other languages, it is possible to request space for multiple variables, and then convert a pointer to any value in that set into a pointer to any other variable within that set.

Many compilers implement pointers by using their bits store actual machine addresses, but that is not the only possible implementation. An implementation could keep one array--not accessible to user code--listing the hardware address and allocated size of all of the memory objects (sets of variables) which a program was using, and have each pointer contain an index into an array along with an offset from that index. Such a design would allow a system to not only restrict code to only operating upon memory that it owned, but also ensure that a pointer to one memory item could not be accidentally converted into a pointer to another memory item (in a system that uses hardware addresses, if foo and bar are arrays of 10 items that are stored consecutively in memory, a pointer to the "eleventh" item of foo might instead point to the first item of bar, but in a system where each "pointer" is an object ID and an offset, the system could trap if code tried to index a pointer to foo beyond its allocated range). It would also be possible for such a system to eliminate memory-fragmentation problems, since the physical addresses associated with any pointers could be moved around.

Note that while pointers are somewhat abstract, they're not quite abstract enough to allow a fully-standards-compliant C compiler to implement a garbage collector. The C compiler specifies that every variable, including pointers, is represented as a sequence of unsigned char values. Given any variable, one can decompose it into a sequence of numbers and later convert that sequence of numbers back into a variable of the original type. Consequently, it would be possible for a program to calloc some storage (receiving a pointer to it), store something there, decompose the pointer into a series of bytes, display those on the screen, and then erase all reference to them. If the program then accepted some numbers from the keyboard, reconstituted those to a pointer, and then tried to read data from that pointer, and if user entered the same numbers that the program had earlier displayed, the program would be required to output the data that had been stored in the calloc'ed memory. Since there is no conceivable way the computer could know whether the user had made a copy of the numbers that were displayed, there would be no conceivable may the computer could know whether the aforementioned memory might ever be accessed in future.