我们为内部客户开发产品。我们没有 QA 团队，也不使用断言。性能很重要，应用程序大小不重要。
最好有一个配置（而不是分离Debug和Release），它会有调试信息（pdbs），也会做性能优化？
这种方法有什么缺点吗？
【问题讨论】：
标签： c++ visual-studio configuration debugging release
单身可以吗 配置，而不是分离 调试和发布（在我们的例子中）？
可能没问题 - 这在很大程度上取决于您的情况（但取决于您的详细信息，我认为这非常不可以）。
我们没有 QA 团队，也不使用断言。
断言不是调试版本的问题。它们是您可以使用（或不使用）的另一种工具。
是否拥有 QA 团队不应（严重）影响调试和发布版本之间的决定（但如果您有 QA 团队，迟早您可能希望拥有产品的调试版本）。
QA 团队会严重影响您的产品质量。如果没有专门的 QA（由开发应用程序的人其他人），您无法保证产品的质量或稳定性，您无法保证它会做它应该做的事情（或它适用于任何目的），并且您无法在很多领域对您的产品进行有意义的测量）。
您可能实际上并不需要 QA 团队，但在大多数情况下，您只是剥夺了您的开发团队和客户（内部或非内部）的大量必要数据。
调试版本应该更容易 - 嗯 - 调试您的产品并跟踪问题并修复它们。如果您没有进行有组织的 QA，您甚至可能不知道要解决的主要问题是什么。
我认为您实际上有一个 QA 团队，但您并没有这样看待它：您的内部客户（甚至可能是您）是您的 QA 团队。这是一个坏主意，因为您的应用程序的功能很重要。
在没有 QA 团队的情况下工作就像自己制造一辆汽车并在路上进行测试：您不知道车轮是否可以固定在一起，或者直到您在交通中才能正常工作。可能是你不杀任何人，但我不会把你公司的关键数据放在你未经测试的应用程序中，除非它不是很关键。
性能很重要，应用程序大小不重要。
如果性能很重要，谁来衡量它？测量代码是否属于您发布的应用程序？在发布的代码中添加和删除吗？
听起来您正在进行临时开发，并且使用的是性能关键型应用程序，没有 QA 团队，也没有专门的调试，我非常怀疑您的团队能否真正交付。
我不知道你的情况，可能有很多我看不到，所以也许没关系。
这种方法有什么缺点吗？
是的：您最终会在发布版本中使用诊断代码，或者必须在修复每个问题后删除诊断代码，然后在处理下一个问题时再次添加。
你不应该仅仅为了优化而删除调试版本。这不是一个有效的论点，因为您可以优化您的发布版本并保持调试版本不变。
【讨论】：
调试和优化往往相互矛盾。编译器的优化通常会使调试变得很痛苦（函数可以内联、循环展开等），并且使调试信息有价值的严格性束缚了编译器的手，因此它也无法优化。基本上，如果将两者结合起来，那就是两全其美了。
因此，成品的性能几乎要求它是“发布”版本，而不是调试版本，当然也不是两者的奇怪组合。
【讨论】：
调试信息在优化的构建中几乎毫无价值，因为优化器会将程序变成无法识别的东西。此外，如果您有带有其他优化标志的辅助配置，则与未定义行为相关的错误更容易暴露。
【讨论】：
你应该至少有两个。一个用于发布（性能），一个用于调试 - 或者您是否每次都编写完美的代码？
【讨论】：
我会说您应该始终将调试版本和发布版本分开。发布版本适用于您的客户，调试版本适用于您的开发人员。你说你不使用断言：也许你应该是？即使您不在自己的代码中使用断言，您仍然可以在底层库代码中触发断言，例如在使用无效迭代器时。这些将给开发人员一个错误的警告。如果用户看到这条消息会怎么做：恐慌、致电技术支持、什么也不做？
调试版本可以在您发布发布版本之前为您提供额外的工具来解决问题。您应该使用所有可用的工具来提高产品质量。
【讨论】：
两者都保留。有两种配置是有原因的！ Debug 用于调试，Release 用于日常使用。
“合并”配置的缺点是显而易见的 - 使用干净的发布配置不会获得最佳优化，并且调试会很尴尬。用不同的配置重建项目所需的几秒钟（或几分钟）是值得的，相信我。
【讨论】：