Question

Debug版的内存管理问题

我VC2005写了一个链表管理一些数据，如果当链表占用的内存超过我设定的400M，就会将使用的最少的数据删除。这里当然是new和delete的对应。代码应该没问题。
在release版的时候，从windows的任务管理看内存的占用是符合设计的目标。
而用debug版的时候，从windows的任务管理看进程的内存占用也是没问题的。但问题是，尽管任务管理器显示进程的内存占用在设定之内和release一样。但系统的可用物理内存却在不断的减少直到不能再分配内存。
难道说debug里面释放内存的内存并没归还给系统？所以导致new的次数越多，实际占用的内存会不断增加？

Answer 1

你用的不是286以前的产品吧，386以后的intel IA-32结构处理器都支持16位下的分段内存寻址模式，这是为了向后兼容，而现在在32或64位环境下编写16位程序（比如DOS程序）的时候，使用的是386以后CPU提供的"virtual 8086"（虚8086模式），只是一个模拟环境罢了，所以你在cmd里使用16位程序，比如debug时，你会注意到窗口有一些小的变化。这时其实已经进入了虚8086模式。模拟始终是模拟，自80386中的有一代开始，intel就是32根地址总线了，奔腾又多加了4根，现实中我们使用的是32位CPU，32位系统，平坦型的内存模式使程序可以在4GB的范围内寻址，奔腾可以大到64GB，所以当然可以寻到类似于10FFEF的地址咯。

所以现在的什么DOS程序都是在cpu的虚模式下运行，包括一些古老的C编译器比如TC2.0。

虽然DOS汇编老了点，但我觉得由此了解下cpu的发展还是很不错的，能为以后的32位汇编打下基础。

补充：那是因为debug是16位的程序，FFFFF已经大于了16位，所以debug当然可以发现这类明显的错误，但由段+偏移地址计算出的地址就不知道咯，具体要看它程序本身的实现，也有可能是16位程序移植到32位环境下做了某些改动所造成的结果吧，纯属猜想，仅供参考。

Answer 2

debug是16位dos上的调式器，如果你用的是windows,你必须创建基于VDM(DOS虚拟机)的exe程序，使用x86的虚拟8086来运行程序，此时的内存地址是0040:0017形式的。你可以给指针赋硬值来访问所有内存空间。
例：
char far * pvf = 0x40017;
*pvf = (你所要赋的值 ）;

如果你编写32windows程序，内存地址是32位的，例如0x0045C320形式。x86机器上使用实模式，开启分页机制。用指针只能访问本进程的地址空间，访问任意进程地址空间可以用WriteProcessMemory函数

Answer 3

你的程序设计的问题，明显的内存泄露。