开发单个可执行文件时使用不同的C ++编译器和语言版本

我们公司将购买大量且非常复杂的卫星通信源代码。

它使用C ++进行编码，我们还将使用C ++对其添加的代码进行编码，将我们的代码与购买的代码链接到单个可执行单元中。

• 是否有必要使用与开发购买的代码相同的编译器和相同的编译器版本？

• 我们是否必须使用与所购买代码相同的C ++版本？如果不使用2014，我们可能想使用它的某些功能，但是如果混合使用不同的版本可能会出现问题，则不要。

从理论上讲，当然，这无关紧要，尤其是语言版本，但是可以想象，不同版本的编译器将生成不同的目标代码，从而可能导致时序差异等。

我们应该注意什么？

是否有必要使用与开发购买的代码相同的编译器和相同的编译器版本？

这取决于。

编译器生成针对ABI的代码。有些使用了通用的ABI（例如，如果我没记错的话，clang ++和g ++都将目标对象称为Itanium ABI），并且您应该-可能有一些错误阻止您这样做-能够使用目标代码在同一个程序中同时使用这两个文件（当然，假设您使用的是针对ABI相同版本的版本）。编译器版本之间的情况也是如此：与其他版本相比，有些人更注意保持相同的ABI。显然，他们有时都需要更改ABI，并且可能会被迫以不兼容的方式进行更改。显然，某些设置（例如语言标准的选择）可能会影响ABI的选择。

然后是标准库的问题。编译器（或同一编译器的不同版本）本身可能使用相同的ABI，但它们的标准库可能不兼容（某些编译器（如clang ++）可能与几个标准库一起使用）。能否使其工作可能取决于界面中使用的内容。

换句话说，你必须挖掘和寻找你在特定情况下的信息。作为出发点和类型的信息，你应该寻找什么一个例子，这里是的libstdc ++提供（由g使用的库的信息++并通过clang ++进行某些配置）

是否有必要使用与开发购买的代码相同的编译器和相同的编译器版本？我们是否必须使用与所购买代码相同的C ++版本？

这主要不是技术问题。关于您在合同中写的内容是一个法律问题。确保软件供应商为您提供了他保证可以在您的环境中使用的版本。否则，总是有一定的风险会遇到使用其他编译器，编译器版本或语言版本的麻烦。

当您购买组件或部件的一部分作为封闭源时，这一点尤其重要。即使您的供应商保证您可以在当前的编译器环境中使用该组件，但是如果您将来想切换到较新的编译器版本，他是否保证将为您提供更新？如果您无权访问完整的源代码，则尝试自己解决任何兼容性问题可能会很不幸。因此，您不仅应该购买软件，还应该考虑与供应商签订长期维护合同。

我们公司将购买大量且非常复杂的卫星通信源代码。它使用C ++进行编码，我们还将使用C ++对其添加的代码进行编码，将我们的代码与购买的代码链接到单个可执行单元中。

听起来不错！

是否有必要使用与开发购买的代码相同的编译器和相同的编译器版本？

一般而言，没有必要。C ++的目的是作为对此类事物的抽象，因此，编写良好的C ++程序在您的工具链上的编译效果将与在原始作者上进行的一样好，并且所得程序将具有相同的结果。性能可能会有所不同，因为不同的编译器擅长于不同的事情，但是程序的基本行为不应改变。

但是，写得不好的软件可能依赖于特定于实现的行为，甚至取决于未定义的行为。它可以对内置类型或平台的字节序进行假设。甚至是写得很好的软件也别无选择，只能依靠您选择的工具链上不存在的非标准扩展，或者这样做是因为根本没有必要在更新期间内花费时间来添加可移植层。原始项目。

最终，您将需要询问作者/供应商源代码是做什么的。如果他们声称它是针对Visual Studio 2015专门编写的，并且需要Windows API功能，则您可能应该坚持这样做。但是，如果他们声称它是可移植的标准C ++，那么请使用您喜欢的任何编译器。确保您的购买协议包括支持安排，以便在事实证明卖方在撒谎时可以获取免费帮助。

我们是否必须使用与所购买代码相同的C ++版本？如果未使用2014，则可能要使用它的某些功能，但是如果混合使用不同版本可能会出现问题，则不要使用。

大概。也许。

C ++ 03在大多数情况下都是向前兼容的，因此，如果代码是C ++ 03，则您不太可能遇到问题。（尽管可能需要一些调整。）

但是C ++ 11和C ++ 14中引入的功能不向后兼容，因此，如果供应商使用了C ++ 11 lambda，而您尝试在C ++ 03编译器中构建其代码，那将是成功的。不行

从理论上讲，当然，这无关紧要，尤其是语言版本，但是可以想象，不同版本的编译器将生成不同的目标代码，从而可能导致时序差异等。

绝对。如果代码在很大程度上依赖于特定的实现以获得预期的结果，则由供应商负责并通知您。由于我们生活在现实世界中，因此我建议您勤奋工作并先问他们。

我将回应其他人所说的话：确保您拥有某种形式的支持资源，这样，如果他们对这些问题的回答（无论是有意还是无意的）都误导了，您最终都不会承担由此产生的费用。

您不链接代码，而是链接编译的目标文件。

在这种情况下，是的，在构建将以二进制级别交互的部件时，使用不同的C ++编译器（甚至调试/发行版本之类的设置），或它们的不同版本或不同（版本）标准库，很可能会破坏如果零件之间使用多个C API相互通信，则此应用程序有效。

诸如容器或异常之类的功能提供了相同的接口，但是在二进制级别上，可以以许多不同的不兼容方式实现。

但是，使用不同的编译器来编译整个代码是另一个问题。要考虑的问题：

• 代码针对的平台/体系结构是什么？
• 它是为哪个标准制定的？
• 它是否使用任何非标准的编译器功能？
• 代码是否包含硬编码的平台特定假设（例如始终考虑指针占用2个字节）？

代码也可能包含导致未定义行为的部分。使用一种编译器时，这些方法似乎工作正常，但使用另一种编译器时，它们以神秘的方式失败。

是否有必要使用与开发购买的代码相同的编译器和相同的编译器版本？

好吧，切换编译器可能会导致一些问题。当前在我公司中，我们使用Clang和MSVC，并且在一个编译器中出现错误，而另一个未将其标记为此类。

我们是否必须使用与所购买代码相同的C ++版本？如果未使用2014，则可能要使用它的某些功能，但是如果混合使用不同版本可能会出现问题，则不要使用。

这不是必需的，但是您的编译器当然应该支持您要使用的C ++版本。C ++保证从所有版本开始都具有复古兼容性。

更改编译器时的一个大问题是未定义的行为：如果您收到的代码调用未定义的行为，则一切皆有可能-包括该代码工作正常并且在使用其编译器时通过了所有测试，并对编译器造成了严重错误。

这是可能的，但是在这种情况下，如果您更改优化级别，使用同一编译器的下一个版本，您可能还会遇到问题。因此，您无法避免。