為什么 Windows 和 Linux 有不同的 strdup 實現：strdup() 和 _strdup()？

Question

在 Windows 上使用strdup ，我發現_strdup是特定於 Windows 的，但是當我在 Linux 上運行相同的代碼時，它需要不帶下划線的strdup 。 有誰知道這種差異背后的歷史，以及一些關於您在編寫跨平台代碼時如何處理這個問題的信息？

Answer 1

有幾個函數是 POSIX 規范的一部分，即 Linux 和大多數其他 UNIX 變體，它們不是標准 C 的一部分。這些函數包括strdup 、 write 、 read等。

前導下划線的原因如下，取自MSDN 文檔：

通用 C 運行時庫 (UCRT) 支持 C++ 一致性所需的大部分 C 標准庫。 它實現了 C99 (ISO/IEC 9899:1999) 庫，但有一些例外： 中定義的類型通用宏，以及 中定義的嚴格類型兼容性。 UCRT 還實現了 POSIX.1（ISO/IEC 9945-1:1996，POSIX 系統應用程序接口）C 庫的一個大型子集。 但是，它並不完全符合任何特定的 POSIX 標准。 UCRT 還實現了一些不屬於標准的 Microsoft 特定功能和宏。

特定於 Microsoft 的 Visual C++ 實現的函數可以在 vcruntime 庫中找到。 其中許多函數供內部使用，不能由用戶代碼調用。 一些文檔用於調試和實現兼容性。

C++ 標准將全局命名空間中以下划線開頭的名稱保留給實現。 POSIX 函數和 Microsoft 特定的運行時庫函數都在全局命名空間中，但不是標准 C 運行時庫的一部分。 這就是為什么這些函數的首選 Microsoft 實現具有前導下划線的原因。 為了可移植性，UCRT 還支持默認名稱，但 Microsoft C++ 編譯器在編譯使用它們的代碼時會發出棄用警告。 僅棄用默認名稱，而不是函數本身。 要取消警告，請在使用原始 POSIX 名稱的代碼中包含任何標頭之前定義 _CRT_NONSTDC_NO_WARNINGS。

我已經通過#define檢查程序是否正在為 Windows 編譯，如果是，則創建另一個#define以將 POSIX 名稱映射到 Windows 特定名稱。 您可以檢查幾個選項，但最可靠的可能是_MSC_VER ，如果 MSVC 是編譯器，則該選項被定義。

#ifdef _MSC_VER
#define strdup(p) _strdup(p)
#endif