MSVC 将调试代码与发布代码混合
问题的动机：生成 64 位和 32 位代码需要两个单独的完整程序编译，并且在使用 Visual Studio 时（如下所述），发布和调试版本不兼容，因此似乎需要另一个两个完整程序编译（总数达到四个）。我想坚持使用两个完整的程序编译，但我很困惑。
调试时我关心的是：全局状态、堆栈帧以及导致崩溃的代码的行号/文件。另外，我不关心来自同行评审的高度稳定的开源库的调试信息；因此，我不需要这些库的调试信息，并且该库的发布版本应该足够了。
证据：我知道，在 VS 中，如果您编译应用程序的调试版本并将其与 Google Protocol Buffers 的发布版本链接，则生成的代码将由于混合的副作用而失败发布/调试类型。
我想知道这是否是使用 Visual Studio 的副作用，并且某些编译器开关会导致这种情况。
其次，检查开源项目的构建脚本/流程，似乎可以将调试模式下生成的代码与发布中生成的代码混合在一起（例如 咕哝）。我想这与release和ReleaseWithDebugInfo（借用自cmake的术语，但这显然可以在Visual Studio中表达）之间的区别有关。 ReleaseWithDebugInfo 毕竟是二进制文件的优化版本，还生成了调试信息，因此适合发布。
问题：
- 有人可以解释一下或提供参考资料，说明哪些开关使代码不兼容。
- Visual Studio 中的 ReleaseWithDebugInfo 编译风格是否足以满足调试和发布用例（根据我的标准，如上所述）？ --即，编译器在调试模式下生成的内容是否过度或多余？
- 在 ReleaseWithDebugInfo 模式下（对于我的应用程序），我可以在发布模式下编译外部依赖项（没有调试信息）并且没有任何未定义的行为吗？
Motivation for Question: Generating 64-bit and 32-bit code requires two seperate full-program-compiles, and when using visual studio (as detailed below) release and debug builds are incompatible, therefore seemingly requiring another two full-program-compiles (bringing the total up to four). I would like to stick with two full-program-compiles, but I am confused.
When Debugging All I Care About Is: the global state, the stack frame, and the line-number/file of the code that caused the crash. Also, I don't care about debug info from peer-reviewed highly-stable open-source libraries; therefore, I don't need debug-info for those libraries and a release build for this libraries should be adequate.
Evidence: I know that, in VS, if you compile a debug version of an application and link it with a release version of Google Protocol Buffers, the produced code will fail due to a side-effect of mixing release/debug types.
I would like to know if this is a side effect of using visual studio, and a certain set of compiler switches make it so.
Secondly inspecting the build scripts/processes of opensource projects it seems that it is OK to mix code generated in debug mode with code generated in release (for example mumble). I guess this has something to do with the distinction between release and ReleaseWithDebugInfo (term borrowed from cmake, but this is obviously expressable within Visual Studio). ReleaseWithDebugInfo is afterall an optimised version of the binary, with debugging info also generated, and therefore suitable for release.
The Questions :
- Could someone please explain, or provide references, as to what switches make the code incompatible.
- Is the ReleaseWithDebugInfo style of compiling in visual studio enough for both debug and release use-cases (according to my criteria, as explained above)? --i.e., is whatever the compiler generates in debug mode overkill or redundant ?
- In ReleaseWithDebugInfo mode (for my application) can I compile external dependanies in release mode (without debug info) and not have any undefined behaviour ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
调试模式（我认为你的意思是未优化）代码是否“过度杀伤”取决于你想用它做什么。
如果您想使用调试器、非常准确地步进行并检查遇到的任何变量，则需要关闭优化。如果您不太关心这一点，那么您可以将其保持打开状态，并忍受调试器中的一些奇怪行为。
如果您进行编辑并继续编译，则会在该位置周围放置大量填充以允许部分编译/链接。
因此，未优化的代码存在大量“过度杀伤”和“冗余”，但它们可能仍然有价值。
链接不同配置的常见问题是当它们共享由运行时库的不同版本/配置分配的对象时。如果您在库之间使用 Win32 风格的“C”风格接口，那么您很少关心一个是调试还是一个发布。如果您使用一种运行时版本在堆上分配 CString，然后将其传递给使用不同运行时释放分配的代码，那么通常会出现问题。
这里您需要考虑三件不同的事情：
这只是您真正需要变得完美的最后一项。另外两个是个人喜好。
Whether debug mode (by which I take it you mean unoptimized) code is 'overkill' depends on what you want to do with it.
If you want to use the debugger, stepping lines very accurately and inspecting any variable you come across, you'll need to turn off optimisation. If you don't care some much about that, then you can leave it turned on, and put up with some strange behaviour in the debugger.
If you compile for edit-and-continue, there'll be lots of padding put around the place to allow partial compiles/links.
So there is lots of 'overkill' and 'redundancy' to unoptimised code, but they may still be valuable.
The usual problem with linking different configurations is when they're sharing objects allocated by different versions/configurations of the run-time-libraries. If you're using a Win32-style 'C'-style interface between libraries, then you rarely care if one's debug and one's release. If you allocate a CString on the heap with one version of the run-time, and then pass it to code which deallocates with a different run-time, then there will often be problems.
There are three different things you need to think about here:
It's only the last one you really need to get perfect. The other two are personal preference.