我在两台不同的机器上工作。一个是Windows，另一个是Linux。如果我交替使用同一个项目但在两个操作系统之间切换，我最终会遇到编译错误吗？我问，因为可能有一个标准支持，而另一个标准不支持。
答案 0 :(得分：2)
仅当您的应用程序使用某些特定API时才可能。
答案 1 :(得分：2)
这个问题非常广泛，严格来说，这取决于您的工具链。如果您使用相同的工具链（例如GCC / MinGW或Clang），您将最大限度地减少此类错误的可能性。如果您在Windows上使用Visual Studio，在Linux端使用GCC或Clang，那么由于某些标题不同，您会遇到更多问题。因此，一旦你的程序离开严格的ANSI C（C89）领域，你就可以独立完成。
但是，如果你不小心，你可能会遇到很多其他更亵渎的错误，比如如果你没有告诉你在Windows端的编辑使用这些错误，那么Linux上的编译器就会在行结尾处窒息。
啊，还要记住，如果你想实际交叉编译，GCC可能是最好的选择，因此我在答案中提到的第一部分变得没有实际意义。 GCC在两端都是经过验证的选择。并且考虑到你的问题，你不太可能尝试编写像内核模式驱动程序这样的东西 - 这将是根本不同的。
答案 2 :(得分：1)
完全可以编写适用于两个平台的代码，编译代码没有任何问题。然而，它并非没有一些困难。编译器允许您在编译器中使用非标准功能，并且通常很难做更多花哨的用户界面（即使它仍然只是文本），因为只要您开始想做的不仅仅是“读取一行文本，因为它进入“壳”，它进入“非标准”土地。
如果你确实发现自己需要做的不仅仅是标准C库可以做的事情，请确保将代码的这些部分隔离到一个单独的文件中（或者一些文件，一个用于Linux / Unix风格的系统和一个对于Windows系统）。
使用相同的编译器（gcc）将有助于避免“编译器B无法编译在编译器A中正常工作的代码”的问题。
但这绝对不是绝对必要的 - 只要确保你在两个平台上编译代码，并且经常使用你所有的“支持”编译器，以至于你没有挖出一个很难找到的深洞。你发现“它不适用于其他系统”。如果您（至少）有一台运行其他操作系统的虚拟机，这肯定有帮助，因此您可以轻松尝试这两种变体。
理想情况下，您希望设置一个自动化系统，这样当您更改代码[并认为更改是“完整”]时，它会自动构建在您要使用的平台和所有编译器上。如果可能的话，也会自动测试！
我也会认真考虑使用版本控制 - 这样，当一方或另一方出现问题时，您可以返回并查看代码在停止工作之前的样子，并（希望）找到原因打破的速度比“嗯，我认为这是我对foo.c的改变，让我们把它拿出来......不，不是那个，好吧这里的变化怎么样......” - 至少在版本控制方面，你可以说“好吧，所以版本1234不起作用，让我们试试版本1220 - 好吧，确实有效。现在尝试1228，仍然有效 - 所以在1229和1234之间改变 - 尝试1232，啊，它已经坏了...”没有编辑文件，你仍然可以很轻松地去你喜欢的任何其他版本。我已经使用了Mercurial，git一点，一些颠覆，并在Perforce工作了几年。所有这些都很好 - 就个人而言，我认为我更喜欢善变。
作为一个副作用：大多数版本控制系统还以更加理智的方式处理文件名和行结尾，而不是手动执行此操作。
如果您将版本控制系统与“自动构建和测试系统”（如Jenkins）结合使用，则可以使所有内容都非常自动化。 Jenkins是免费的，可在Windows和Linux上运行，您可以在将代码提交到版本控制系统时使用它自动构建和测试代码。
答案 3 :(得分：0)
在相应的操作系统中重新编译源代码之前，不会产生问题。如果你想运行由windows（.exe或.obj）生成的编译文件，进入linux或反之亦然，那么它肯定会产生问题并且不可能。但是您可以将源代码（扩展名为.c / .c ++的文件）移动到任何操作系统中。有时它也会产生不同头文件的问题，所以也要照顾它。最佳实践是为整个项目使用单个操作系统，避免多个操作系统，直到它非常必要。