MSVC 混合调试代码和发布代码答案

【问题标题】：MSVC Mixing Debug Code with Release CodeMSVC 混合调试代码和发布代码
【发布时间】：2011-05-07 05:34:32
【问题描述】：

问题动机：生成 64 位和 32 位代码需要两个单独的完整程序编译，并且在使用 Visual Studio（如下所述）时，发布和调试版本不兼容，因此似乎需要另外两个完整的程序编译（总共最多四个）。我想坚持使用两个完整的程序编译，但我很困惑。

调试时我只关心：全局状态、堆栈帧以及导致崩溃的代码的行号/文件。另外，我不关心来自同行评审的高度稳定的开源库的调试信息；因此，我不需要这些库的调试信息，并且这些库的发布版本就足够了。

证据：我知道，在 VS 中，如果您编译应用程序的调试版本并将其与 Google Protocol Buffers 的发布版本链接，则生成的代码将由于以下原因而失败 -混合发布/调试类型的效果。

我想知道这是否是使用 Visual Studio 的副作用，并且某些编译器开关会导致这种情况。

第二次检查开源项目的构建脚本/进程，似乎可以将调试模式下生成的代码与发布中生成的代码混合在一起（例如mumble）。我想这与 release 和 ReleaseWithDebugInfo （从 cmake 借用的术语，但这显然可以在 Visual Studio 中表达）之间的区别有关。 ReleaseWithDebugInfo 毕竟是二进制的优化版本，还生成了调试信息，因此适合发布。

问题：

有人可以解释或提供参考，说明哪些开关使代码不兼容。
Visual Studio 中的 ReleaseWithDebugInfo 编译风格是否足以用于调试和发布用例（根据我的标准，如上所述）？ --即，编译器在调试模式下生成的东西是矫枉过正还是多余？
在 ReleaseWithDebugInfo 模式下（对于我的应用程序）我可以在发布模式下编译外部依赖项（没有调试信息）并且没有任何未定义的行为吗？

【问题讨论】：

标签： visual-c++ build-process compilation cross-compiling toolchain

【解决方案1】：

调试模式（我认为你的意思是未优化）代码是否“过度杀伤”取决于你想用它做什么。

如果您想使用调试器，非常准确地单步执行并检查您遇到的任何变量，您需要关闭优化。如果您对此不太在意，则可以将其保持打开状态，并在调试器中忍受一些奇怪的行为。

如果您为编辑并继续进行编译，则会在该位置周围放置大量填充以允许部分编译/链接。

因此，未优化的代码有很多“过度杀伤”和“冗余”，但它们可能仍然很有价值。

链接不同配置的常见问题是当它们共享由运行时库的不同版本/配置分配的对象时。如果您在库之间使用 Win32 风格的“C”风格接口，那么您很少关心一个是调试还是一个发布。如果你在堆上分配一个运行时版本的 CString，然后将它传递给使用不同运行时解除分配的代码，那么通常会出现问题。

您需要在这里考虑三件不同的事情：

我需要调试符号吗？ - 您可以在任何调试/发布配置中进行这些操作
我需要良好的可调试性还是需要良好的代码优化？
大家都在用什么 CRT/STL/什么版本？

这只是你真正需要变得完美的最后一个。另外两个是个人喜好。

【讨论】：

我遗漏的 CRT 版本，谢谢（它提出了问题的另一个方面：D）。您知道为什么一个库的发布版本会导致另一个库的调试版本产生故障二进制文件吗？（在我的示例中）CRT 与 C 风格的界面应该是相同的天气协议缓冲区在发布或调试时编译。
我不知道任何关于协议缓冲区的细节。在 Debug 中分配和在 Release 中释放（反之亦然）的一般问题是它们可能使用不同的块头进行分配（或执行不同的有效性检查）
感谢您回复我，分配是在 CRT 的一部分函数中执行的，还是编译器生成的代码？我只想知道细节，所以我知道要避免什么。例如，如果修复了差异，我可以让调试版本链接到发布 CRT，同时仍然获得高度可调试的应用程序。
我上一条评论的进一步补充： 如果问题是由于 CRT 的发布和调试版本引起的，则不使用 CRT 的代码（但低级别的 ansi-c 库）可以链接到任一版本而不会引起问题——无论天气如何，它都经过优化。如果是这种情况，我的问题得到了解答，我会知道要避免什么。
CRT 是低级 ANSI-C 库。在一个库中分配对象并在另一个库中释放它们是不安全的。