爲什麼string.h庫中有太多函數是「不推薦使用」的呢？

我試圖理解C語言的起源，爲什麼有些功能不推薦用於大多數SO問題。像strtok或strncpy，他們根本不安全的工作。在Evrywhere中，我看到了recomendations寫我自己的實現。爲什麼標準不會改變strncpy例如BSD strlcpy，而是留下這些「怪物」？爲什麼string.h庫中有太多函數是「不推薦使用」的呢？

來源

2013-07-21 yevgeniy mordovkin

「Evrywhere我看到recomendations寫我自己的實現」 - 不要相信他們。 'strtok（） - > strtok_r（）'，'strncpy（） - > memcpy（）'，不管。原因＃1：向後兼容。原因2：C標準庫是標準化的（真是一個驚喜），但沒有人關心。相反，操作系統和工具鏈供應商不斷推出自己的擴展。 – 2013-07-21 20:01:42

如果你瞭解他們的特定故障或限制，他們中的許多人都可以使用。例如'strtok'不是線程安全的，但如果你只是簡單地編寫一個單線程程序，那麼這沒有問題。同樣''strncpy'可能是「不安全的」，但使用明確定義的輸入可以。關鍵是要了解*爲什麼*某些功能已被替換或棄用。通過遵循像libc這樣的庫的發展，您可以學到很多東西。 –

「strncpy」的問題對於「定義明確的輸入」不是問題，而是該函數不適用於將字符串複製到其他字符串。 'strncpy（）'的目的是將一個字符串複製到一個_null填充的固定大小的buffer_中。不是「空終止」，而是「空填充」。副本的目標_is不是string_，它是一個固定大小的緩衝區。所以，如果你明白自己在做什麼，'strncpy（）'完全可以安全使用，人們會告訴你「不推薦」的原因是它容易被誤用爲'strcpy（）'的安全替代方法，這不是。 –

C是70年代初的產物，它表明。許多更爲先進的圖書館功能是在C用戶社區規模很小，僅限於學術界的時候編寫的，其中大部分都是經驗豐富的程序員。在1989年發佈第一個標準時，這些原始庫函數已經在10到15年的遺留代碼（其中最重要的是Unix操作系統及其大部分工具）中佔據了優勢。負責標準化的委員會不願意打破現有的代碼庫，所以這些功能幾乎是按原樣納入標準;所有真正改變的是將原型語法添加到聲明中，並在必要時將char *更改爲void *（malloc，memcpy,memset等）。

AFAIK，只有一個庫函數實際上已從中刪除自標準化以來的語言 - gets。由一個圖書館電話造成的混亂比打破現在近四十年的遺留代碼的前景更加可怕。

來源

2013-07-22 11:26:37

道德故事：厭惡根深蒂固的遺留代碼。 –

放下你想要的一切，但那不會讓它消失。我正在研究一個真正需要從龍骨上廢棄和重建的系統，但這是永遠不會發生的。故事的真正寓意是歷史是一個苛刻的情婦。 –

他們仍然存在，因爲與「舊系統」 /「代碼」仍然使用他們的歷史祖傳的關係 - 即支持「向後兼容」

自己的實現，建議讓程序員使用自己的邏輯由於沒有人可以更好地瞭解他們的環境，所以程序員自己也是如此，例如strtok不是線程安全的。

來源

2013-07-21 20:40:31 P0W

「沒有人能更好地瞭解他們的環境，那麼程序員本人」並不是很有說服力。 C意味着成爲一種編程語言，而不是彙編程序，爲什麼每次都要重新發明輪子，如果我們可以給程序員需要的所有東西，就像Java標準庫一樣。 –

這裏有很多傳統的「C」和「C++」代碼。如果他們從「C」運行時庫中刪除了所有「不安全」功能，那麼許多開發人員將升級其編譯器，因爲所有舊代碼都不會再構建它，這是令人望而卻步的。

有時他們會給出「不推薦」的編譯器消息（MSFT喜歡這個），所以你會發現並改變使用新的，更安全的功能。

新代碼應該使用「安全」功能，當然，但我們很多人都堅持與老編譯器和遺留代碼保持:)

來源

2013-07-21 20:46:16 edtheprogrammerguy

嗯，這是我的預期:)另外一個原因，我猜測，缺乏優秀的C庫是1）難以編寫它們2）大多數用C寫的人使用它來進行非常硬件的關閉操作，所以他們實現了他們所需要的最小的事情，其餘的代碼處理與位相關的邏輯。 –

如果是你正在尋找的答案，請接受:) – edtheprogrammerguy

-1

這一切都只是教條。使用這些函數只是意識到他們對你的目標漠不關心，因爲他們可能無法在所有情況下工作（例如，strtok和多線程），或者他們期望在使用前後捕獲條件（即strncpy和缺少終止字符）。

來源

2013-07-21 21:05:38

爲什麼string.h庫中有太多函數是「不推薦使用」的呢？

回答

相關問題