这是C ++使用G ++ 4.1.2 CentOS的64位。
我们正在编写一个测试程序由n个千兆字节加载了一个系统对内存的占用。这个想法是，整个系统的负载获得通过SNMP等监测所以这只是一个行使监督的方式。
但是什么我们所看到的是简单地做：
char* p = new char[1000000000];
不影响所使用的存储器，如图顶部或免费-m
内存分配似乎只能成为“真正的”曾经的记忆被写入：
memcpy(p, 'a', 1000000000); //shows an increase in mem usage of 1GB
但是，我们必须写入所有的记忆，只是写的第一个元素没有显示在使用的内存增加：
p[0] = 'a'; //does not show an increase of 1GB.
这是正常的，有记忆里却得到了充分的分配呢？我不知道这是否是我们使用（顶部和免费-m）所显示不正确的值或者是否有编译器或运行时和/或内核正在进行一些聪明的工具。
这种行为被看作即使在调试版本与优化关闭。
这是我的理解是一个新的[]立即分配的内存。请问C ++运行时的延迟访问它这个实际分配到以后。在这种情况下，可以在内存溢出异常推迟到井内存的实际分配后，直到内存被访问？
由于它是它是不是我们的问题，但它会很高兴地知道这是为什么发生的事情是这样的！
干杯!
编辑：
我不想知道我们应该如何使用的载体，这是不是OO / C ++ /处事等等等等的电流方式，我只是想知道这是为什么发生的事情是这样的，而不是有任何建议对于尝试它的替代方式。
请查一下去了过量使用。直到它被访问的Linux默认不保留内存。如果你需要通过比更多的可用内存结束了，你没有得到一个错误，但一个随机过程被杀死。您可以控制与/proc/sys/vm/*此行为。
IMO，过量使用应该是每个进程的设置，而不是全球性的。和默认的应该是没有过量使用。
当您的图书馆从操作系统分配内存，操作系统将只保留在进程的虚拟地址空间的地址范围。没有任何理由，直到你使用它的OS实际提供这种记忆 - 因为你证明。
如果你看一下例如/proc/self/maps你会看到的地址范围。如果你看一下上面的内存使用，你不会看到它 - 你不使用它。
关于你问题的后半部分：
语言标准不允许在抛出bad_alloc的任何延误。这一定会发生，以替代新[]返回一个指针。它不能在以后发生！
有的操作系统可能会尝试过量使用内存分配，后来失败。这是不符合C ++语言标准。