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