c - 在 C 中正确处理平台细节(unix/windows)？

Question

这个问题故意非常笼统，虽然我在这里和那里涉猎，但我不是 C 程序员。下面的代码故意含糊不清，可能无法编译，但我希望你能明白我的意思……

在像 C 这样的编译语言中，处理平台细节似乎是动态的，这似乎是不必要的，甚至是可怕的:

int main(int argc, char *argv[]) {
    if (windows)
        dowindowsroutine();
    else
        dounixroutine();
    return 0;
}

但是，通过非常基本的宏来处理平台细节似乎也很糟糕，因为函数被分割成可能无法正确编译的小块(阅读对 C #define macro for debug printing 的类似问题的回答)。

int main(int argc, char *argv[]) {
    #ifdef windows
    dowindowsroutine();
    #else
    dounixroutine();
    #endif
    return 0;
}

那么“正确”的方法是什么？是个案处理吗？有没有一种好方法可以让这些粗宏大的宏完全脱离函数？我记得在某处(可能在内核文档或相关内容中)读到宏(更重要的是，复杂的宏逻辑)适用于头文件，而不是 .c 文件。你如何处理这种事情？

我厌倦了函数内部带有 ifdef 的“意大利面条代码”……我认为在某些情况下它可能没问题，但我看到的大多数代码都在滥用它。

注意:我看到一些 perl XS 代码看起来像是将函数原型(prototype)包装到 和 东西，但这是唯一的方法吗？这在社会上是不是有点恶心？或者这样可以吗？来自 perl、python、shell 等主要“脚本化”背景……我很难说。

更新:让我更清楚一点，我试图避免的问题是我不想要断断续续的代码。我希望能够确保如果我的代码在 linux 的编译时中断，它也会在 windows 的编译时中断。使用断断续续的代码，可能会破坏 windows 的编译，但不会破坏 linux，反之亦然。这种事情可能吗？到目前为止最接近的是 ifdef'ing 整个函数，但函数名称相同，是否有更好的解决方案，只有一个接口(interface)，但操作系统特定部分将其操作系统名称嵌入到名称中？

Answer 1

我认为处理这个问题的正确方法是将您的代码库拆分为特定于平台的模块，并在构建时将它们组装起来(这当然需要某种平台抽象层。)这样您的 Unix 代码就不会乱七八糟了Windows 调用，反之亦然。实际上，您将令 ifdef 头疼的事情转移到了 makefile 上。