Categories

Calendar

January 2018
M T W T F S S
« Jun    
1234567
891011121314
15161718192021
22232425262728
293031  

久别重逢的 std::bad_alloc

久别重逢是说,自从在教科书上见过它一面之后,这才是第二次碰面。也就是说,在这些年的编程经历中,从来没有遇到过吧——至少在我印象中是这样的。以至于我都开始怀疑在“平常的”程序中,它是否真正存在了。内存分配,C 里的 malloc (或者配套的函数) ,如果分配失败了会返回地址 0 ,所以,“作为良好的编程习惯,每次申请内存之后,应该检查一下返回值是不是 NULL ”,这样的“良好习惯”也许刚开始写几个程序的时候还能坚持,到后来就完全不管了——因为从来没有遇到过 malloc 返回 0 的情况,申请内存怎么会失败呢?如果连内存都申请失败了,那接下去估计也没有什么好做的了,估计系统已经处于崩溃边缘了,与其每次都费力去检查,还不如让它自生自灭好了——反正之后如果尝试去访问这个 0 地址,肯定会碰到段错误 (segment fault) 而挂掉的,当然,一个不好的地方可能就是这个挂掉的位置和最初申请内存失败的位置已经相差了十万八千里,可能追踪起来会比较麻烦。

至于 C++ 里,就更简单了,new 的时候如果申请不到那么多内存的话,会抛出 std::bad_alloc 异常,如果没把这个异常接住,让它一直跳到最顶层的话,程序会立即挂掉。比 C 更加“人性化”——当场挂掉,而不是在某个未知的其他地方 segment fault 。如此一来,就更加熟视无睹了。

总而言之,渐渐地有了这样一种印象:像内存申请失败之类的情况,大概只有在嵌入式设备等非常极端的资源匮乏的平台上编程的时候才会碰到吧。结果这次却在一个内存很大很大(256G 物理内存)的环境里遇到了。果然是和车祸之类的类似,越是在看上去很太平的路段,越会让驾驶员掉以轻心呀。