我最近接手了一个用 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 代码）。
如果您刚刚接管了一个大型项目，那么修改编译器设置应该是一个低优先级。在开始更改可能会破坏代码并使您难以调试问题的选项之前，请先了解代码库。或者换一种说法，避免寻找能让你在很短的时间内取得巨大成就的 Deus Ex Machina。使用分析器将使您获得更大的收益和更好的洞察力。