Automatically add C++11 override to virtual methods

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 build 2036 is available

After living for two months with a beta version of Visual Assist on our website, we are happy to reach another general release. Visual Assist build 2036 has two significant improvements that make this a must-have, must-use, build.

First, build 2036 introduces a new command—Goto Related—that lets you jump to locations related to your current symbol. Goto Related is part class browser, part goto. Locations vary with symbol type, but include definition of a type, base classes, and derived classes. Use Goto Related to jump anywhere into a hierarchy.


Access Goto Related using its default shortcut (Shift+Alt+G), different shortcut assigned to VAssistX.GotoRelated, or via VAssistX in the menubar. Learn more in the documentation for Goto Related.

Second, build 2036 introduces a new editor for VA Snippets (upgraded if you were using our beta build.) The new editor organizes VA Snippets by type, and auto-sorts them, so you needn’t grapple with the “yard sale” of VA Snippets in our previous editor. The completely new interface includes the ability to search—by string and regular expression—across types for VA Snippets.


The new editor is available in Microsoft Visual Studio 2010 and newer, but because VA Snippets are shared across IDEs, simply edit your VA Snippets in a modern IDE if you still maintain projects in an old IDE.

Learn more in the documentation for the VA Snippet editor.

Build 2036 includes a number of other improvements, as well as fixes related to stability and performance. You must have software maintenance through 2014.05.22 to run build 2036. Check the About dialog of Visual Assist to find out if you qualify. If not, renew maintenance for another year of updates.

Learn more about what’s new in build 2036, or go directly to download the installer.

Implementing Virtual Methods with Visual Assist

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.

Scope of Refactoring in Universal Solutions

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.