Visual Studio 2003编译器行为

Question

I recently took over a project written in C and C++ that will be compiled using the MS Visual Studio 2003 compiler. Since I have a little lack on experience with compiler settings and compiler output I want to know if the given setup realy makes a difference (according to compilation output or performance).

The project uses a mixture of C and C++. The main part is written in C but uses some classes written in C++. So the first part of the question is: does the (MS VS 2003) compiler makes a difference per file (compiling plain c for .cpp files using only c functionality and compiling c++ style for files using the classes)? Could there be a reason for using that (performance boost, backward compatibility)?

The project also does not use try-catch blocks (since it is not plain C). But the exception handling options in the compiler settings are not disabled. So the second part of the question: could there be still a performance boost (or any other logical reason) for not using try-catch but NOT disabling it in the compiler?

Yes, I am quite confused by this setup and trying to understand.

Answer 1

Fairly hard to decode, I'll give it a shot. The default behavior is to get the C compiler when the source code filename extension ends in .c and the C++ compiler when it ends in .cpp. There is no greater scheme behind this, or anything having to do with backwards compatibility or perf improvements, a .cpp file is simply expected to contain C++ code. Both compilers use the same back-end (code generator and optimizer) so there will not be any great difference if you compile C code with the C++ compiler.

The /EH compile option only does something if you create C++ objects in your code and the compiler can tell that an exception might be thrown. If the codebase is largely C based then it won't make any difference. The actual cost of /EH is very low, a few cpu cycles to register an exception filter. There's no cost when exception handling uses function tables but yours is almost surely too old to support that (/SAFESEH or x64 code).

If you just took over a large project then tinkering with the compiler settings ought to be a low priority. Get to know the codebase first before you start changing options that may break the code and will give you a hard time debugging the problem. Or to put it another way, avoid looking for the Deus Ex Machina that will make it look like you made a great achievement in very little time. Using a profiler will get you much more bang and a better insight.