strcpy是眾所周知的最危險(xiǎn)函數(shù)之一，它不判斷目標(biāo)緩沖區(qū)是否足夠長，而strncpy要好一點(diǎn)，但它從某種意義上講，卻比strcpy還危險(xiǎn)方：當(dāng)目標(biāo)緩沖區(qū)滿時(shí)，它不在尾部加零，也就是說，程序員也許會(huì)以為用了個(gè)安全的函數(shù)，結(jié)果拷貝過去的字串卻可能不是以零結(jié)尾！！
這個(gè)函數(shù)的替代品是strsafe.h中的StringCchCopy()
二、危險(xiǎn)且低效的sprintf()
sprintf（以及printf系列）不但危險(xiǎn)，而且低效。首先，它與strcpy一樣，沒有判斷目標(biāo)緩沖區(qū)的長度，其次，它只能在運(yùn)行時(shí)刻判斷參數(shù)的類型和個(gè)數(shù)（也就是說，如果你的格式字符指定了“%s: %d”，但你傳的參數(shù)個(gè)數(shù)不符，或者類型不符，只有在運(yùn)行時(shí)刻才會(huì)爆發(fā)出來）。
從安全角度上講，這個(gè)函數(shù)的替代品是strsafe.h中的StringCchPrintf()，但如果同時(shí)再考慮效率，用C++的輸出流更好（比如ostringstream），因?yàn)檩敵隽鞯母袷交窃诰幾g時(shí)刻決定的。
三、printf系列的錯(cuò)誤用法（同樣適用于StringCchPrintf
StringCchPrintf(outString, countOfOutBuffer, sourString)這種用法是相當(dāng)危險(xiǎn)的，它希望達(dá)到與StringCchCopy相同的效果，但它會(huì)在sourString中包含有“%d %s”這種程序員意料之外的冬冬時(shí)，產(chǎn)生嚴(yán)重的后果。正確的做法是：無論在任何情況下，printf系列函數(shù)都必須包含“明確的格式化字串”，比如sprintf(outString, "%s", sourString)。
四、貌似安全的strsafe.h中的系列函數(shù)
StringCchCopy等函數(shù)，有一個(gè)很討厭的地方，就是它們不判斷源字符指針是否為NULL，也就是說，如果我們傳遞一個(gè)NULL指針給它，希望它理解為一個(gè)空串，而它卻會(huì)產(chǎn)生一個(gè)零地址訪問違例。這個(gè)也許并不嚴(yán)重，但卻會(huì)讓漫不經(jīng)心不仔細(xì)閱讀文檔的程序員大吃一驚，而我這里想說的是，這個(gè)并不是它們真正不安全的地方，真正不安全的地方其實(shí)在于它們并未把程序員從“必然管理字串長度和零結(jié)尾”中解脫出來，比方說程序員會(huì)提供一個(gè)錯(cuò)誤的目標(biāo)緩沖區(qū)長度，特別是在寬字符環(huán)境下，錯(cuò)誤地傳遞了目標(biāo)緩沖區(qū)的字節(jié)數(shù)，而不是字符數(shù)。
五、幸好有了STL
STL提供的模板類basic_string規(guī)避和解決了上述所有問題，讓C++程序員也擁有了類似于DELPHI中的原生String，再配合輸入輸出流（輸入流解決格式化輸入問題、輸出流解決了格式化輸出），從此“必須管理字串及緩沖區(qū)長度”、“必須補(bǔ)零”等問題，不再是C++程序員需要考慮的了！
六、你還只是一個(gè)C程序員嗎？
拋開OO不談，如果你還在自己管理字符串，那你就還只是一個(gè)C程序員。（附注：不代表BS這門語言以及它的程序員們，只是在字符串這個(gè)軟脅上，我們應(yīng)該能做得更好）。