準(zhǔn)確地說還是經(jīng)驗(yàn)不足，這么簡單的事居然想了好幾分鐘，當(dāng)然也要怪VS在沒有重新生成前的詭異現(xiàn)象。
今晚在類中加入兩個(gè)數(shù)組用來做計(jì)數(shù)，因?yàn)橹按a有所改動(dòng)，VS編譯（增量）的結(jié)果居然出現(xiàn)了無數(shù)次的程序崩潰，害我一度懷疑是不是我的數(shù)組寫的有問題。囧。最后無奈之下，點(diǎn)了重新生成，居然順利通過了，很生氣，憤怒中。
但是另外卻發(fā)現(xiàn)了一個(gè)問題，也就是當(dāng)size_t用作循環(huán)的時(shí)候。因?yàn)橐郧岸际怯胕nt做循環(huán)的，現(xiàn)在換成unsigned int（也就是size_t）后，一下子沒反應(yīng)過來，就順手這么寫了：
for( size_t i = MAX - 1; i >= 0; --i)
{
//……
}
乍一看似乎沒啥問題，因?yàn)槲已h(huán)內(nèi)的代碼是刪除資源的，因此程序也頻頻崩潰。
step over的結(jié)果才讓人驚訝，因?yàn)楫?dāng)size_t i = 0的時(shí)候，--i的結(jié)果是無窮大，而無窮大則肯定滿足i>=0的條件，所以當(dāng)我們期待程序停住的時(shí)候，程序是不會(huì)停住的。
修正的方式：
1、使用正向遍歷。
2、增加判斷條件（i>=0 && i < MAX），但這里也可能存在問題，因?yàn)閟ize_t可能被定義為unsigned int，但是MAX可能是個(gè)更大的數(shù)，比如unsigned long long，當(dāng)然這樣的比較不是很有意義，或者會(huì)實(shí)現(xiàn)一些轉(zhuǎn)換，但是如果這種情況發(fā)生的話，程序可能還是會(huì)通過一個(gè)隨機(jī)的i進(jìn)入到一個(gè)未知的空間中，從而造成崩潰。而且增加判斷條件也使得程序的運(yùn)行成本提高。