Sometimes you may see errors there is nobody's fault about but they are still errors. Imagine that a long-long time ago (in Visual Studio 6.0) a project was developed that contained the class CSampleApp which was an derived of CWinApp. The base class had the function WinHelp. The derived overridden this function and performed all the necessary actions.

1. Lesson 12. Pattern 4. Virtual functions
Sometimes you may see errors there is nobody's fault about but they are still errors. Imagine that a
long-long time ago (in Visual Studio 6.0) a project was developed that contained the class CSampleApp
which was an derived of CWinApp. The base class had the function WinHelp. The derived overridden this
function and performed all the necessary actions. It looked as shown in Figure 1.
Figure 1 - Correct operable code created in Visual Studio 6.0
Then the project is ported to Visual Studio 2005 where the prototype of the function WinHelp has
changed. But nobody notices it because the types DWORD and DWORD_PTR coincide in the 32-bit mode
and the program still works well (Figure 2).
Figure 2 - Incorrect yet operable 32-bit code
The error waits to occur on a 64-bit system where the sizes of the types DWORD and DWORD_PTR differ
(Figure 3). It turns out that the classes contain two DIFFERENT functions WinHelp in the 64-bit mode. Of
course it is incorrect. Note that such traps may hide not only in MFC where some functions have
different types of the arguments but in the code of your applications and third-party libraries as well.

2. Figure 3 - The error occurs in the 64-bit code
Let us consider one more error by an example taken from real life. There is a wonderful component
library BCGControlBar. You are likely to have heard about it because some components of BCGSoft Ltd
company are included into Microsoft Visual Studio 2008 Feature Pack. Well, if you download the trial
version of this library, install it and search for the word "WinHelp" through .h-files... you will see that
wherever this function is supposedly overridden the parameter DWORD is used instead of DWORD_PTR.
And it means that Help system will behave incorrectly in these classes when ported to a 64-bit system.
Why can such an error still exist in the code of so popular a library? We think the point is that the
company's clients have access to the source codes of this library and they may always easily correct
these codes. Besides, the function WinHelp is used very rarely nowadays. HtmlHelp is used much more
frequently - and it does have the right parameter DWORD_PTR in BCGControlBar. But the fact remains.
There is an error in real code and the compiler does not detect it. Such errors may stay hidden for many
years.
Note. This text is being written in December, 2009, and it is most likely that this error will be corrected
in the next versions, especially as we have written about it to the developers of the library.
Diagnosis
Errors related to virtual functions in 64-bit code can be detected by the static analyzer PVS-Studio. The
analyzer will warn you about dangerous virtual functions with the diagnostic warning V301.
A virtual function is considered dangerous if:
1. The function is defined in the base class and in the derived -class.
2. The types of the functions' arguments do not coincide but are equivalent on a 32-bit system (for
example: unsigned, size_t) and are not equivalent on a 64-bit one.
The course authors: Andrey Karpov (karpov@viva64.com), Evgeniy Ryzhkov (evg@viva64.com).
The rightholder of the course "Lessons on development of 64-bit C/C++ applications" is OOO "Program
Verification Systems". The company develops software in the sphere of source program code analysis.
The company's site: http://www.viva64.com.
Contacts: e-mail: support@viva64.com, Tula, 300027, PO box 1800.