根据平台选择函数名称的最常用方法是什么？

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操作，并且相同的文件可能很难。