The C++11 standard has been approved and C++14 is around the corner. These new standards define a lot of interesting language features, one of them being support for the override identifier. You can append “override” to a virtual function declaration and tell the compiler that you want to override a virtual method inherited from a base class. If the virtual method does not exist in the base class, or has a different signature, the compiler raises an error and the compilation fails.

Use of override is very useful for detecting errors, at compile time, caused by typos and bad copy-pastes.

Visual Studio has supported override since Visual Studio 2010, and so has Visual Assist. But if you want Visual Assist to insert “override” automatically—when using the code generation feature Implement Virtual Methods—you need to tell it via the Windows Registry.

Note: Beginning with Visual Assist build 2042, you can insert “override” automatically via the options dialog of Visual Assist. The following instructions apply to build 2036 and older.

Exit your IDE(s) so Visual Assist does not overwrite your changes, then using the registry editor, navigate to this key:

HKEY_CURRENT_USER\Software\Whole Tomato\Visual Assist X\<IDE_SPEC>

Change the value of UseOverrideKeywordInImplementInterface from 00 to 01.

Restart you IDE, and from now on, Visual Assist will append override to the signatures of your virtual methods.

This article was contributed by Manuel Maier, student at Hochschule der Medien Stuttgart, Germany.

Visual Assist has a feature—Implement Virtual Methods—that makes it easy to implement an interface, or abstract methods of a base class. You don’t need to create anything manually.

Move the caret to a base or interface class in the declaration of your derived class, or to the derived class if you want to implement methods from all bases classes.

Open a refactoring menu—via the context menu or Shift+Alt+Q—and select Implement Virtual Methods.

A dialog will open, letting you choose the methods to implement.

Visual Assist updates the declaration of your class, and create stubs in its implementation. By default, an exception is placed in the body of each method.

You can change the default by modifying the VA Snippet for “Create from Usage Method Body”.

If you add methods to an interface, repeat the process and Visual Assist will automatically disable existing methods.

The declaration and implementation of your new method will be inserted in the correct locations, relative to the existing methods.

That’s all there is to it.

This article was contributed by Lei Zhu, student at the College of San Mateo, CA.

At the Build 2014 conference in San Francisco, Microsoft announced availability of Universal Solutions in Visual Studio 2013 Update 2 RC. When you are ready to explore the functionality of this major improvement to the IDE, you’ll want to know how several often-used commands of Visual Assist operate in this new arena.

As a review, a simple Universal Solution is one that has at two or more platform-specific projects, and a shared project that is inherited by the platform-specific projects. The solution can include additional projects that may or many not inherit the shared project.

In a Universal Solution of multiple project types, Find References, Rename, and Change Signature behave as they normally do if you tell the commands to display references from, or search in, all projects. A find for Foo::Bar() in all projects locates the method wherever it’s referenced in your solution—in all project types.

But, the three commands assume new behavior in a Universal Solution when you search only the current project: the three commands assume you wish to search the current project plus those the project inherits, or are inherited by the current project. This slightly broader definition of current project prevents you from inadvertently refactoring code that will break a solution.

For example, if you rename MinPlayableWidth from a reference in a shared project—without telling Rename to search all projects—Visual Assist assumes you also need to rename references in the projects that inherit the shared project.

As another example, if you change signature of Foo::Bar() from a reference in a platform-specific project, Visual Assist assumes you also need to change the signature of Foo::Bar() in the shared project, plus other projects that inherit the shared project.

Even with the broader definition of the current project within a Universal Solution, you still have the opportunity to select/deselect project nodes before committing to a refactoring. If you exploit Rename or Change Signature to “refactor” your code so it references a difference object, e.g. Foo::Bar2(), you might initiate a Rename or Change Signature, then deselect nodes of projects that inherit, or are inherited by, your current project.

In summary, Visual Assist assumes you want your solution to build when you refactor in a Universal Solution. If you’re using refactoring commands for non-refactoring purposes, be mindful of the scope of your changes before you commit to them.