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