Sometimes you may see errors there is nobody’s fault about but they are still errors. Imagine that a long-long time ago (for example, 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 15.
Figure 15 – Correct operable code created in Visual Studio 6.0
Then the project is ported to a later version of Visual Studio, where the prototype of the function WinHelp has changed. But nobody notices it because the types DWORD and DWORD_PTR coincide in the 16-bit mode and the program still works well (Figure 16).
Figure 16 – 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 17). 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.
Figure 17 – The error occurs in the 64-bit code
A virtual function is considered dangerous if:
- The function is defined in the base class and in the derived -class.
- 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.