简体   繁体   中英

Visual Studio 2003 Compiler behaviour

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.

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.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM