问Windows上的C编译器之间的实际区别是什么？

EN

当尝试将为MSVC编写的代码编译到其他编译器时，首先要做的是在关闭Microsoft扩展的情况下编译它。(我想应该使用/Za标志)。这会让很多事情烟消云散，而GCC和其他编译器会抱怨这些事情。

下一步是确保特定于Windows的API (MFC、Win32等)被隔离在特定于windows的文件中，有效地将代码划分为“通用”和“特定于windows”的模块。

还记得这样的争论吗?如果你想让你的网页在不同的浏览器上工作，那么你就应该编写符合标准的HTML。

编译器也是如此。

在语言层面，如果您的代码在使用-std=c89 (或C++的-std=c++98 )、-pedantic -Wall和-Wextra的GCC平台上编译时没有任何警告，而且只要您没有使用过-pedantic允许的任何更明显的GNU扩展(这很难意外地做到)，那么它很有可能在大多数C89编译器上运行。C++就不那么确定了，因为您可能依赖于目标编译器对该标准的支持程度。

编写正确的C89有一定的限制(没有//注释，声明必须在一个块中的语句之前，没有inline关键字，没有stdint.h，因此没有64位类型，等等)，但一旦你习惯了，这并不是太糟糕。如果你只关心GCC和MSVC，你可以打开MSVC有的一些语言特性。否则，您可以编写自己的小“语言抽象”头文件。例如，在GCC和MSVC/C++上将"inline“定义为"inline”，而在MSVC/C ++上定义"__inline“，或者MSVC stdint.h很容易找到或编写。

我过去成功地写过可移植的代码--我主要是在一个平台上工作，使用的是一个特定产品的平台，使用的是GCC。我还编写了适用于所有平台的代码，包括Windows XP和Mobile。在构建服务器上运行“测试构建”之前，我从未为这些平台编译过它，而且我很少遇到任何问题。我想我可能写了一两次触发64位兼容性警告的糟糕代码。

Windows程序员走另一条路导致了偶尔的问题，主要是因为他们的编译器没有我们那么书呆子气，所以我们看到了他们不支持的警告，而不是GCC根本不支持的东西。但修复警告意味着，当代码稍后在具有更多原始编译器的系统上使用时，它仍然可以工作。

在库级别，这要困难得多。如果你通过windows.h #include和使用windows.h，那么很明显它不会在linux上工作，如果你和GCC一起使用KDE，然后尝试用MSVC编译，情况也是一样。

严格地说，这是一个平台问题，而不是编译器问题，但它等同于同一件事。如果您想要编写可移植的代码，则需要一个操作系统抽象API，如POSIX (或其子集)，所有目标都支持它，并且在编写它时，首先需要考虑“可移植性”。使用大量使用特定于windows的API的代码，并试图使其在GCC/linux上工作，基本上是完全重写AFIAK。使用WINE可能比尝试重新编译它更好。

你把“编译器”和"OSs“搞混了。不是MSVC C编译器带来的东西:它是Windows API的C特定实现。您可以从Visual Studio独立获得它。任何其他Windows上的C编译器都可能提供它。例如，在Linux端，您可以使用、和其他工具。它们不是GCC的重要组成部分，任何其他为Linux编译的编译器都会提供它们。

所以你需要回答两个不同的问题:我如何才能以一种任何编译器都能接受的方式编写C代码？我如何隐藏我对操作系统的依赖关系？