我最近接手了一个用 C 和 C++ 编写的项目，该项目将使用 MS Visual Studio 2003 编译器进行编译。由于我在编译器设置和编译器输出方面缺乏经验，因此我想知道给定的设置是否确实会产生影响（根据编译输出或性能）。
该项目混合使用了 C 和 C++。主要部分是用 C 编写的，但使用了一些用 C++ 编写的类。 所以问题的第一部分是：（MS VS 2003）编译器对每个文件有影响吗（仅使用 c 功能为 .cpp 文件编译纯 c，并使用类为文件编译 c++ 样式）？ 使用它是否有原因（性能提升、向后兼容性）？
该项目也不使用 try-catch 块（因为它不是普通的 C）。但编译器设置中的异常处理选项并未禁用。 所以问题的第二部分：不使用 try-catch 但不在编译器中禁用它是否仍然可以提高性能（或任何其他逻辑原因）？
是的，我对这个设置很困惑并试图理解。
解码相当困难，我会尝试一下。 默认行为是当源代码文件扩展名以 .c 结尾时获取 C 编译器，当源代码文件扩展名以 .cpp 结尾时获取 C++ 编译器。 这背后没有更大的方案，或者与向后兼容性或性能改进有关的任何事情，.cpp 文件只是期望包含 C++ 代码。 两个编译器都使用相同的后端（代码生成器和优化器），因此如果使用 C++ 编译器编译 C 代码，不会有太大差异。
/EH 编译选项仅在您在代码中创建 C++ 对象并且编译器可以判断可能会引发异常时才会执行某些操作。 如果代码库主要基于 C，那么它不会有任何区别。 /EH 的实际成本非常低，几个 cpu 周期即可注册一个异常过滤器。 当异常处理使用函数表时没有任何成本，但你的函数表几乎肯定太旧而无法支持它（/SAFESEH 或 x64 代码）。
如果您刚刚接手一个大型项目，那么修改编译器设置应该是低优先级的。 在开始更改可能会破坏代码并使您很难调试问题的选项之前，请先了解代码库。 或者换句话说，避免寻找会让你看起来像在很短的时间内取得了巨大成就的“杀出重围”。 使用分析器会让您获得更多的收获和更好的洞察力。