仔細(xì)想想能導(dǎo)致一個(gè)C++程序崩潰的幾乎90%原因都是跟指針有關(guān)。空指針野指針，一不小心
程序就崩了。寫(xiě)C++程序的人基本上都知道這個(gè)問(wèn)題。在我們周?chē)苊膺@些問(wèn)題的常規(guī)方法
也很多，諸如auto_ptr（及其他基于template的原始指針wrapper）、SAFE_DELETE。當(dāng)然也
會(huì)有很多人在實(shí)現(xiàn)一個(gè)函數(shù)時(shí)會(huì)很勤勞地對(duì)每一個(gè)parameter進(jìn)行合法判斷。
其實(shí)，我們都知道，auto_ptr這些東西始終是無(wú)法避免野指針和空指針帶來(lái)的災(zāi)難。
SAFE_DELETE也不能阻止別人使用這個(gè)空指針。
在我看過(guò)的一些開(kāi)源項(xiàng)目的代碼中，這些代碼給人的感覺(jué)就是別人總能詳細(xì)地掌控各種資源
（包括指針及其他變量）的使用情況。相比之下，公司隔壁組的老大則顯得保守很多。他要
求我們幾乎要對(duì)所有指針的使用進(jìn)行空值判斷（野指針也判斷不了），當(dāng)然，各種成員變量
也要進(jìn)行即使現(xiàn)在看上去沒(méi)多大用的初始化。
也許，這樣做后程序是不會(huì)掛掉了。但是，就我們的觀點(diǎn)來(lái)看，這樣反而會(huì)隱藏一些BUG。
為什么我們不能詳盡地去管理一個(gè)指針？一個(gè)指針變?yōu)榭樟耍偸且驗(yàn)樵谶@之前發(fā)生了錯(cuò)誤
。當(dāng)然，野指針本身就是愚蠢代碼產(chǎn)生的東西，這里沒(méi)必要討論。空指針之所以為空，也是
因?yàn)樵诤芏鄷r(shí)候我們把空作為失敗/錯(cuò)誤/無(wú)效的標(biāo)志。
恰好上周我的一些代碼就真的在空指針上出現(xiàn)了問(wèn)題。外網(wǎng)的服務(wù)器隨時(shí)會(huì)因?yàn)橥婕业囊恍?br>臨界操作行為而崩潰掉。雖然我通過(guò)修改腳本來(lái)屏蔽這個(gè)問(wèn)題（因?yàn)椴荒苷f(shuō)停機(jī)維護(hù)就停機(jī)
維護(hù)），但是總感覺(jué)程序是不安全的。人不吃點(diǎn)教訓(xùn)絕對(duì)不學(xué)乖。
后來(lái)我對(duì)這個(gè)問(wèn)題徹底思考了一下。很多程序員都自認(rèn)聰明。在寫(xiě)C++程序時(shí)，我從來(lái)不提
供沒(méi)用的public接口，尤其是set/get。我也從來(lái)不對(duì)沒(méi)必要的成員變量進(jìn)行初始化。我給
的理由是對(duì)于這些東西我都有很清晰的把握，我為什么要做stupid的事情？
但是，我?guī)缀鯊膩?lái)沒(méi)有界定，指針在哪些情況下需要去判斷為空？函數(shù)的參數(shù)絕對(duì)不需要。
假如函數(shù)的參數(shù)就是個(gè)空指針，那是client程序員的責(zé)任。僅供模塊內(nèi)使用的指針（包含其
他資源）在內(nèi)部使用時(shí)也不需要去判斷。如果去判斷了，那說(shuō)明你對(duì)你自己寫(xiě)的模塊都缺乏
精確的把握，證明你的設(shè)計(jì)思維不夠清晰。
什么時(shí)候需要判斷？當(dāng)指針依賴(lài)于外部環(huán)境時(shí)，例如讀配置文件、載入資源，因?yàn)橥獠恳蛩?br>不確定不在自己控制范圍內(nèi)，那么進(jìn)行判斷。同樣，當(dāng)使用了其他模塊返回的指針值時(shí)，也
需要判斷。這個(gè)其實(shí)和“外部環(huán)境”屬于同一種情況。因?yàn)槲覀儗?duì)其他模塊也不清楚，更為
隱蔽的是（隨著其他模塊的改變，將來(lái)會(huì)在你的模塊里爆發(fā)崩潰錯(cuò)誤），其他模塊由別人維
護(hù)，其變化更不受自己控制。之前我對(duì)這一點(diǎn)界定不是很清楚，這也是我犯錯(cuò)的原因。
現(xiàn)在想想，像游戲服務(wù)器這種程序，里面塞著各種各樣的游戲功能。無(wú)論是哪一個(gè)模塊出現(xiàn)
個(gè)空指針訪問(wèn)出錯(cuò)的問(wèn)題，都會(huì)直接讓服務(wù)器崩掉。關(guān)鍵是這個(gè)結(jié)果經(jīng)常伴隨著玩家的損失
。所以理想狀態(tài)下，把每一個(gè)模塊都放置在單獨(dú)的進(jìn)程里，確實(shí)是很有好處的。