Application Security Testing: An Integral Part of DevOps
In a continued examination of the new Visual C++ 2005 IDE Enhancements, this article looks at the code definition window, editor enhancements, changes to class view, and finally, one of the big new additions to Visual C++: the class diagram.
IntelliSense Revisited (Briefly)
Part 1 of this series on the Visual C++ 2005 IDE covered enhancements to IntelliSense as they relate to macros and displayed a screen shot of the IntelliSense tool-tips for the MAX macro. Zobiuk posted a comment on the article, stating that the particular example I chose to illustrate IntelliSense support for macros has actually worked in Visual C++ for a couple of versions. Zobiuk is correct. I simplified the point in that section to such an extent that it was no longer entirely correct. Thanks to Zobiuk for pointing this out. I appreciate all feedback and act upon it if needed.
The full story on C++ macro IntelliSense is it has been around for a while, but it suffered from bugs related to the way it tracked macro state. These bugs could cause serious problems in the IDE when macro IntelliSense was triggered (this post on microsoft.public.dotnet.languages.vc describes an occurrence of this problem). Visual C++ 2005 fixes this problem, making macro IntelliSense much more useful in this version. Developers who turned off IntelliSense to avoid problems like this should give the improved IntelliSense a try once Visual C++ 2005 hits the streets.
Code Definition Window
Presenting developers with information about the types that they are using to write their code is an ongoing challenge for the IDE. The information has to be relevant, presenting the information has to be non-intrusive, and retrieving the information has to be speedy. IntelliSense plays a major role in providing information on types that are currently available, the methods that these types expose, and the parameters that need to be passed to these methods. If a developer wants to see an overview of a type, he or she needs to locate and open the header file if the type is defined in a traditional C++ manner, or open the object browser if the type is expressed in a binary file like a COM type library or .NET assembly.
To support an easier model than the snakes-and-ladders hunt through nested includes and to end the disconnect between the text-centric editor and the graphic-centric object browser, Visual C++ 2005 introduced a new window called the Code Definition Window. The Code Definition Window automatically provides a header file-style view of the type that the text insertion point is currently within or near. If the type is defined in a header file, the IDE displays the header file in the Code Definition Window. Figure 1 shows the header file that defines std::vector automatically, displayed as code that uses the vector template is being written.
Figure 1: Code Definition Window from Header File
If the definition of the type is contained in a binary file such as a .NET assembly, the IDE generates an equivalent header file declaration for the Code Definition Window. This feature does not work in the current beta of Visual C++, but it works for C#. Figure 2 shows a generated C# file for System.String. The method implementations obviously are missing, but the generated code does include method- and parameter-level comments that are the same as those in the MSDN documentation.
Figure 2: C# Code Definition Window from .NET Assembly
Presenting all this in a single screen continues the trend toward converging all the information that a developer needs into a single view. The Code Definition Window eliminates the need to tab between the MSDN documentation, the object browser, and header files to find information about a type; it automatically locates and displays all the information as the code is being written.
The code editor is the core of the IDE, and it is therefore not surprising that it has been enhanced in a number of ways. One of the more retro enhancements is the ability to emulate the Emacs and Brief editors. While this enhancement will hold little interest to those used to the Visual Studio editor short-cuts, for organizations where development teams have been reluctant to standardize on Visual Studio because of familiarity with these other editors, the emulation support will be a welcome addition.
To enable the emulation modes, choose Tools | Options, and configure as appropriate on the Text Editor dialog (see Figure 3).
Figure 3: Configuring Emacs or Brief Emulation
One of the more mundane but useful editor enhancements is the margin coloring that indicates lines of code that have been modified since the source file was opened (shown in green) and lines of code that have been modified since the source file was saved (shown in gold). Figure 4 shows this change tracking.
Figure 4: Editor Change Tracking
While this change tracking does not in any way replace the need for a source control tool, it does enable a quick check before a save or a build to ensure that all the changes are correct and that inadvertent modifications have not been made.
The ability to customize the editor has been dramatically expanded in Visual Studio 2005. A setting that may have been represented by a single check-box or drop-down in Visual Studio 2003 may now have dozens of different options that allow the setting to be fully customized. For example, the number of items in the Fonts and Colors option dialog that can have separate settings applied has increased from eight in Visual Studio 2003 to 23 in the current November 2004 CTP release of Visual Studio 2005.
The final noteworthy editor enhancement is the enhanced ability to display Unicode text and to use it as variable names in a C++ project. An attempt to use a non-ASCII variable name in Visual C++ 2003 produces an error: error C3209: '????' : Unicode identifiers are not yet supported. In Visual C++ 2005, the code shown in Figure 5 saves, compiles, and runs correctly. The Simplified Chinese text shown is AltaVista.com's translation of Hello World.
Figure 5: Enhanced Unicode Support