关于《C语言深度解剖》182和415的探讨.doc

C语言深度解剖的作者是个善于观察、思维缜密的人，在其著作中提出了许多值得思考的问题和细节，对于理解计算机系统原理具有很好的参考价值。这两天拜读了此书，今天跟大家一起探讨一下书中一个关于指针的有趣现象。如果你尚未读过原文，请先阅读原书对应的如下章节：*以下是原文*4.1.5，编译器的bug？另外一个有意思的现象，在Visual C+ 6.0 调试如下代码的时候却又发现一个古怪的问题：int *p = (int *)0x12ff7c;*p = NULL;p = NULL;在执行完第二条代码之后，发现p 的值变为0x00000000 了。按照我么上一节的解释，应该p的值不变，只是p 指向的内存被赋值为0。难道我们讲错了吗？别急，再试试如下代码：int i = 10;int *p = (int *)0x12ff7c;*p = NULL;p = NULL;通过调试，发现这样子的话，p 的值没有变，而p 指向的内存的值变为0 了。这与我们前面讲解的完全一致。当然这里的i 的地址刚好是0x12ff7c，但这并不能改变“*p = NULL;”这行代码的功能。为了再次测试这个问题，我又调试了如下代码：int i = 10;int j = 100;int *p = (int *)0x12ff78;*p = NULL;p = NULL;这里0x12ff78 刚好就是变量j 的地址。这样的话一切正常，但是如果把“int j = 100;”这行代码删除的话，又出现上述的问题了。测试到这里我还是不甘心，编译器怎么能犯这种低级错误呢？于是又接着进行了如下测试：unsigned int i = 10;/unsigned int j = 100;unsigned int *p = (unsigned int *)0x12ff78;*p = NULL;p = NULL;得到的结果与上面完全一样。当然，我还是没有死心，又进行了如下测试：char ch = 10;char *p = (char *)0x12ff7c;*p = NULL;p = NULL;这样子的话，完全正常。但当我删除掉第一行代码后再测试，这里的p的值并未变成0x00000000，而是变成了0x0012ff00，同时*p 的值变成了0。这又是怎么回事呢？初学者是否认为这是编译器“良心发现”，把*p 的值改写为0 了。如果你真这么认为，那就大错特错了。这里的*p 还是地址0x12ff7c 上的内容吗？显然不是，而是地址0x0012ff00 上的内容。至于0x12ff7c 为什么变成0x0012ff00，则是因为编译器认为这是把NULL 赋值给char 类型的内存，所以只是把指针变量p 的低地址上的一个字节赋值为0。至于为什么是低地址，请参看前面讲解过大小端模式相关内容。测试到这里，已经基本可以肯定这是Visual C+ 6.0 的一个bug。所以平时一定不要迷信某个编译器，要相信自己的判断。当然，后面还会提到一个我认为的Visual C+ 6.0 的一个bug。还有，这个小小的例子，你是否可以在多个编译器上测试测试呢？*以上是原文*到此，相信你对作者所发现的有趣现象已经有所了解，现在就让我们通过实验+观察+分析，给这一现象一个合理的解释，一起来探讨一下，为什么会产生这种现象，这究竟是否是VC 6.0编译器存在的bug？首先看作者给出的第一个例子：int *p = (int *)0x12ff7c;*p = NULL;p = NULL;注意0x12ff7c的由来。作者是通过在变量p之前先定义变量i，然后在调试模式下观察到i的存储地址为0x12ff7c，接着将变量i的定义去掉，令p指向地址0x12ff7c对应的存储单元。不同的系统此值一般不同，这取决于操作系统为进程分配的内存空间（主要是堆栈区）的不同，请大家自行替换成合适的值。在我的计算机系统上调试时，对应的地址是0x0013ff7c。接下来请大家测试如下代码，并对比四条printf语句的输出：int *p;printf(&p=%x,p=%xn,&p,p);p = (int *)0x0013ff7c;printf(&p=%x,p=%xn,&p,p);*p = NULL;printf(&p=%x,p=%xn,&p,p);p = NULL;printf(&p=%x,p=%xn,&p,p);以下是输出结果：&p=13ff7c,p=cccccccc&p=13ff7c,p=13ff7c&p=13ff7c,p=0&p=13ff7c,p=0通过观察我们可以发现，变量p自定义以来，其存储位置（&p）并未改变，始终是0x13ff7c，随着对p或*p的操作发生变化的是p值。到此，大家已经隐约觉得这未必是编译器的bug了吧？继续分析！大家一定注意到了：&p恰好也是0x13ff7c，与p所指向的地址一致，这正是关键所在！语句p = (int *)0x0013ff7c使得p恰好指向其本身（这一点作者可能并未意识到，其实这很正常，分给该进程的堆栈空间起始位置固定，i原本在p之前紧挨着p定义，现将其去掉，自然原本应分给i的位置便分配给了变量p，而且int型和指针型都占4个字节的存储空间）。理解此问题的关键在于正确区别&p和p，&p表示系统为指针变量p分配的存储空间的位置，而变量窗口中显示的p值，代表为变量p所分配的存储单元中存储的内容，即它所指向的变量的地址。作者通过*p=NULL将p所指向的内容改为0，不就是将p值改成0了么？由此可见，此现象并非编译器有bug，而是作者不慎混淆了&p和p的含义！再看作者最后举的一个例子，我仍将相应的地址改为0x13ff7c：char *p = (char *)0x13ff7c; /0x13ff7c原是字符型变量ch对应的地址，现为变量p的首地址*p = NULL;p = NULL;作者正确观察到，执行完*p = NULL后，p的值并未变成0x00000000，而是变成了0x0013ff00，同时*p 的值变成了0。这究竟是怎么回事呢？这里，指针p依然是指向自身，但此时的p为字符型指针，*p代表的仅为4字节变量p起始存储地址对应的字节，对于x86体系结构（little-endian）来说，是变量p内容的最低字节。执行完*p = NULL后，p内容的最低字节变为0（即*p变为0），即原来的最低字节0x7c被换成了0x00（注意此前p的内容为0x0013ff7c），于是p的内容变为0x0013ff00，即此时p已经指向新的地址0x0013ff00。不习惯在debug模式下观察变量值的读者可以用下面的代码去观察输出结果：char *p; /此时已为变量p分配空间，但未初始化，其指向不定printf(&p=%x,p=%xn,&p,p); p = (char *)0x0013ff7c;printf(&p=%x,p=%xn,&p,p);*p = NULL;/p的最低字节被改为0x00printf(&p=%x,p=%xn,&p,p);p = NULL;/p值（4字节）被置零printf(&p=%x,p=%xn,&p,p);输出结果为：&p=13ff7c,p=cccccccc&p=13ff7c,p=13ff7c&p=13ff7c,p=13ff00&p=13ff7c,p=0通过上述实验与分析，我们可以发现，理论分析与实验结果完全吻合，编译器工作正常，并不存在什么所谓的bug。欢迎大家发现问题，共同探讨，加深理解，天天进步！hpcs_忽然又想起一个问题，1.8.2有关循环优化：*以下是原文*1.8.2，循环语句的注意点【建议1-27】在多重循环中，如果有可能，应当将最长的循环放在最内层，最短的循环放在最外层，以减少CPU 跨切循环层的次数。例如：*以上是原文*其实，右边的循环之所以比左边的效率高，本质原因并非是循环长短的问题，而是与程序访问的局部性和Cache命中率有关。计算机专业毕业的学生应该很清楚这个问题，在操作系统和体系结构课程中一般都会探讨此问题。我们知道，数组在计算机中是行优先存储的（即本行的最后一个元素与下一行的第一个元素地址相邻），左边的循环中，依次访问的是变量a00，a10，a20，a990，a01，a11，a21，a991，这实际上是按照列优先的原则在访问数组元素。如果Cache容量相对于数组容量而言不够大，考虑一个极端情况，假设Cache只有一个块，只能存储一行数据，则每访问一个元素就会发生一次Cache失效，就需要访问一次主存，读入一块数据，导致存储系统效率低下，明显影响操作延迟。而右边的循环采用的是行优先访问原则，与元素存储顺