我最近接管了使用MS Visual Studio 2003编译器编译的用C和C++编写的项目。由于我在编译器设置和编译器输出方面的经验有点欠缺，我想知道给定的设置是否真的有所作为（根据编译输出或性能）。Visual Studio 2003编译器行为
该项目使用C和C++的混合。主要部分用C语言编写，但使用了一些用C++编写的类。 所以问题的第一部分是：MS（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，这会让你看起来像是在很短的时间内取得了伟大的成就。使用分析器可以让您获得更多的乐趣和更好的洞察力。