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