根據平臺選擇函數名稱的最常用方法是什麼？

Question

我目前在由兩個編譯器編譯的代碼中使用popen函數：MS Visual Studio和gcc（在Linux上）。我可能想在稍後添加gcc（在MinGW上）。

的函數被調用popen的GCC，但_popen爲MSVS，所以我增加了以下到我的源代碼：

#ifdef _MSC_VER 
#define popen _popen 
#define pclose _pclose 
#endif 

這工作，但我想了解是否存在一個標準的解決方案這樣的問題（我記得與stricmp/strcasecmp類似的情況）。具體來說，我想了解以下內容：

1. 是_MSC_VER右邊的標誌取決於？我選擇它是因爲我的印象是linux環境是「更標準」。
2. 如果我把這些#define放在某個頭文件中，我在#include之前還是之後stdio.h（對於popen的情況）是否很重要？
3. 如果_popen被定義爲一個宏本身，有沒有機會我的#define會失敗？我是否應該使用像my_popen這樣的「新」令牌來代替它？
4. 有人已經爲我做了這份工作，並做了一個很好的「可移植性標題」文件，我可以使用嗎？
5. 還有什麼我應該知道的？

Answer 1

你這樣做的方式很好（與#ifdef等），但你測試的宏不是。 popen是依賴於您的操作系統而不是您的編譯器。

我會去像

#if defined(_POSIX_C_SOURCE) && (_POSIX_C_SOURCE >= 2) 
/* system has popen as expected */ 
#elif defined(YOUR_MACRO_TO DETECT_YOUR_OS) 
# define popen _popen 
# define pclose _pclose 
#elif defined(YOUR_MACRO_TO DETECT_ANOTHER_ONE) 
# define popen _pOpenOrSo 
# define pclose _pclos 
#else 
# error "no popen, we don't know what to do" 
#endif 

Answer 2

1. _MSC_VER是用於檢測MSVC編譯器的正確宏。您可以使用__GNUC__作爲GCC。

2. 如果你要使用popen爲宏ID，以後我建議你#include它，因爲3

3. 如果你#include它stdio.h之後，它應該AFAIK工作，但有備無患，不是嗎？叫它portable_popen什麼的。

4. 許多項目（包括我的一些項目）都有一個可移植性頭文件，但通常會更好地推出自己的頭文件。如果你有時間，我很樂意自己做事。因此，您知道代碼的詳細信息（如果出現問題，則更易於調試），並且您可以獲得適合您需求的代碼。

5. 不是我所知道的。我一直都這樣做，沒有問題。

Answer 3

1. 更好地檢查特定Windows的定義（_WIN32也許），因爲MinGW的不會有它的。 popen（）是標準化的（這是一個part of the Single UNIX® Specification v2）
2. 否;只要宏在首次使用之前被定義，如果_popen（）直到後面才定義，那麼它並不重要。
3. 否;即使_popen是一個宏，你所擁有的也很好。
4. 已經完成了很多次，但我不知道可以使用的免費許可版本。

Answer 4

而是包含#ifdef .. #else .. #endif塊雜亂的文件結束了，我用不同的文件在不同的平臺寧願一個版本：

• 把OS相關的定義在每個平臺一個文件和#define宏my_popen
• #include您的平臺不可知代碼中的此文件
• 從不直接調用OS函數，但您創建的#define（即， my_popen）
• 根據您的操作系統，使用匯編不同標題（例如：在Windows config/windows/mydefines.h和config/linux/mydefines.h在Linux上，所以設置包括路徑適當始終#include "mydefines.h"）

這是一個比具有OS更清潔的方法決定源頭本身。

如果你調用行爲Windows和Linux之間的不同，決定哪一個應是你使用的行爲方法（即要麼總是窗口行爲或總是 Linux的行爲），然後創建包裝方法做到這一點。爲此，您還不僅需要兩個mydefines.h文件，還需要myfunctions.c文件，這些文件位於config/OSTYPE目錄中。

這樣做，您還可以在比較linux和windows版本時獲得優勢：您可以簡單地比較兩個文件，同時在linux上執行diff操作，並且相同的文件可能很難。