The C++ compiler in Visual Studio Team System (unlike Visual Studio Standard or Professional editions) has the command line switch /analyze. This switch allows you to launch the static analysis module integrated into Team System to search for some errors in code.
Static analysis in Team System can be enabled not only from the command line but from the shell as well. To do so you should choose the tab Configuration Properties->C/C++->Advanced and enable "Enable Code Analysis For C/C++" as shown in the figure.
This static analysis is rather good and really allows you to find problems in code. But this all is so until you get the message D9040:
Command-Line Warning D9040
ignoring option '/analyze'; Code Analysis warnings are not available in this edition of the compiler
The /analyze command line option is supported only on x86 versions of Visual Studio Team System. It is not available for x64 or Itanium compilers, or for other versions of Visual Studio besides Visual Studio Team System. To remedy this warning, either switch to the x86 version of Visual Studio Team System, or remove the command line option.
Alas, the option /analyze that has only begun to grow popular among programmers is not available for x64 and Itanium compilers. And more of it, this limitation is present both in Visual Studio 2005 and Visual Studio 2008.
That is why, if you need to use static analysis when working with x64 and Itanium compilers there is only one way - use a third-party tool. For example, Viva64 code analyzer included into PVS-Studio that supports both x64 and Itanium platforms besides x86.
I develop the PVS-Studio static code analyzer intended for analyzing C/C++ software. After we implemented general analysis in PVS-Studio 4.00, we received a lot of responses, both positive and negative. By the way, you are welcome to download a new version of PVS-Studio where we have fixed a lot of errors and defects thanks to users who told us about ...
Many programmers think that the more error messages a static code analyzer produces, the better. It would be true if all the messages hit the bull's eye, as they say. But this is impossible: the same warnings may be considered both true and false by different programmers depending on the project type. There is also one more important and interesting ...