关于《0 bug C/C++商用工程之道》的一处bug
这两天有很多朋友已经买了书了,并且开始看,呵呵,我心里也很高兴。
嗯,要说江湖上藏龙卧虎呢,这不,这才几天时间,已经有朋友指出我书中的一处明显错误,这里我正式给大家说明一下,免得对各位读者有个不好的误导。
问题出在第26页的一个图以及其相关文字。这是第二章基础知识的第一节,其实就是关于内存的讲解,大家可以直接在样章中看到。
这论坛里面不好贴图,我就不直接画图给大家看了,简单说,我在书中论述:“32位操作系统下,每个进程空间有4G内存的连续地址可用,其中,高2G是系统使用,低2G是应用程序本身使用,另外,在低2G中,应用程序运行栈在下,即低位地址空间,从下向上生长,堆在上,从上向下分配,什么时候二者碰到一起,什么时候内存就满了,无法运行程序了”。
应该说,我这个说法是不对的,至少是不严谨,因为32位多任务操作系统多种多样,各家操作系统,各家编译器编译出来的运行结果,其实都不一样,我把话说得这么绝对,肯定有问题。这个呢,主要是我写书时不严谨,没有仔细查证资料,写随手了,导致了bug。这里给所有读者先道个歉,下次印刷时,我会和编辑修订这个问题。
我最近查了一下,32位多任务操作系统差别还是很大的,Windows主要是按照2G+2G的分配方式,即操作系统的代码占用2G地址编码,应用程序本身的代码,占用2G,Linux下,则是1G+3G的分配方式,操作系统只占1G地址空间,其它都给应用程序用。
因此,上文简单论述2G+2G,不准确,起码不符合所有操作系统的情况。
“堆在上,栈在下”的理解呢,我更多是来自16位时代的编译器习惯,32位以后情况发生了很大变化,我做了一下试验,VC和gcc均是“堆在下,向上分配,栈在上,向下生长”,和我书中说法是反的。因此必须修订。
我想,这段知识这么理解可能更好,就是应该更加抽象地论述这个问题,而不要说得这么精确。
“32位操作系统下,每个进程空间有4G内存的连续地址可用,其中,有一部分地址空间被系统使用,剩余部分是应用程序本身使用,另外,在应用程序空间中,至少分为程序运行栈和内存堆两个部分,这两部分内存根据应用程序自身运行情况,不断被申请使用和释放,如果二者发生干涉,则表示内存空间耗完,程序将无法运行。”
我在第二章基础知识的本意,是用简单的描述,使各位读者快速对32位操作系统有一个统揽,关于内存的描述,更多的是希望大家能理解上面这几个概念,堆,栈,系统区,应用 程序区等
相关文档:
Boss说,要看OpenGL,看了快一个月,总算出了个像样的东西,用C写了个3D迷宫,
虽然只有350行
代码,不过边学边写,足足写了一周时间,还是小有成就感的,活活活!
&n ......
编译,编译程序读取源程序(字符流),对之进行词法和语法的分析,将高级语言指令转换为功能等效的汇编代码,再由汇编程序转换为机器语言,并且按照操作系统对可执行文件格式的要求链接生成可执行程序。
C源程序头文件-->预编译处理(cpp)-->编译程序本身-->优化程序-->汇编程序-->链接程序--> ......
from: 《自己动手写操作系统》
1. 中断向量表 查看 linux/init/main.c in http://lxr.linux.no/#linux+v2.6.32/init/main.c
2.
; [root@XXX XXX]# nasm -f elf foo.asm -o foo.o
; [root@XXX XXX]# gcc -c bar.c -o bar.o
; [root@XXX XXX]# ld -s foo.o bar.o -o foobar
; [root@XXX XXX]# ./foobar
; the 2nd on ......
今天看到一种比较安全的枚举写法!
enum example
{
item1 = 0,
item2,
item3,
item4,
item5,
max /* when you want to add element,please add before this */
};
当你使用它的时候:
example ex1;
i ......