You are here:

C++/C++ & VC++


What is difference between Virtual functions in C++ and Message Mapping in VC++

Virtual functions are part of the C++ language that provides C++ users with the object-oriented technique of polymorphism.

If I have implied correctly what you mean by message mapping, then message mapping does not exist as part of C++ or the VC++ core language. Message mapping are techniques used by the MFC and ATL (and its extension the unsupported WTL) libraries to map MS Windows operating systems' application messages to specific class handler member functions in MS Windows applications that use the MFC/ATL/WTL libraries. These techniques are specific to these libraries and differ between them. To make their use easier they employ a variety of pre-processor macros.

The problem is that MS Windows messages use a C API: All messages for a window are routed to its handler function. As C has no concept of classes, inheritance or polymorphism these concepts in the context of MS Windows applications are provided by the operating system at runtime. A window class defines a bunch of attributes plus a handler function to receive messages and provide behaviour. There is some concept of sub-classing - such that you can provide an alternate message handler for an existing window class or a specific window instance which gets to handle messages first.

Note that _all_ messages for a window get sent to the same single function and that messages have a pre-defined structure. In fact that is exactly what they are, a C struct:

   typedef struct
       HWND   hwnd;
       UINT   message;
       WPARAM wParam;
       LPARAM lParam;
       DWORD  time;
       POINT  pt;
   }  MSG;

Note that each message contains the window handle for the window it is intended for.  This allows the message to be despatched to the correct handler function based on the windows class of the windows indicated by the hwnd field of the message.

The message type is provided in the message field as well as two parameters of type WPARAM and LPARAM which in 16-bit Windows operating systems (Win16) were 16-bit and 32-bit integer types respectively but are both 32-bits in 32-bit windows (Win32). The meaning of these parameters varies from message to message - often one of them contains a pointer value to more information.

The final two values are a time value indicating when the message was posted and a POINT value indicating the position of the cursor at that time.

From this structure the window function for the target window, the WindowProc, is passed the hwnd, message (passed as a parameter called uMsg in the documentation for some reason), wParam and lParam values.

A typical C-style Windows window class handler function (WindowProc) would contain a switch statement that contained a case for every message the window type is interested in:

   switch ( uMsg )
   case WM_CREATE:
   // initialsie window resources
       return 0;

   // ...
   case WM_SIZE:    /* Size changed... */
       nClientRight = LOWORD( lParam ); /* Update client size */
       nClientBottom = HIWORD( lParam );
       InvalidateRect( hWnd, NULL, TRUE );/* Invalidate whole client rect */
       UpdateWindow( hWnd );   /* Say we want a WM_PAINT */
       return 0;

   case WM_PAINT:
       return 0;

   // ...

   case WM_DESTROY:
   // cleanup window resources
       return  0;

   default:   /* All other messages receive default processing */
       return DefWindowProc( hWnd, uMsg, wParam, lParam );

Such switch statements can get quite large by the time all various messages that need to be handled have their cases. Note that most cases return directly rather than exiting from the switch statement. This is because in general once a message is handled nothing else should need to be done, and the return code indicates the result of the processing and again depends on the message. Note the default case: if a WindowProc is not interested in a message it generally should pass it to the DefWindowProc API function for default processing.

OK so that is a quick 5 minute tour of MS Window application window message handling basics. For more information see the MSDN library (online at try starting at Win32 and Com Development -> User Interface -> Windows User Interface -> Windowing. You could also read a good book on the subject such as Charles Petzold's Programming Windows, 5th edition.

But what about the C++ side? Well we can create a base class. We can add a virtual destructor and virtual functions to the base class. We can create derived classes that override the base virtual function implementation such that when the function is called though a pointer or reference to the base class and the pointed to or referenced object is in fact an instance of a derived class then the derived class' override is called rather than the base class version. This is polymorphism and is a basic object oriented technique.

However the two worlds of Windows application window classes, windows, WindowProcs and messages do not directly map to C++ classes, objects, member functions (virtual or not) and function calls (which effectively constitute messages in C++). They effectively form two similar but not directly compatible worlds. Thus some glue is required to bridge the differences, and part of the end result of such glue code in the case of MFC, ATL and WTL are the various message mappings techniques that involve some sort of message map.

Another problem by the way is associating a window, represented by a window handle, with a window (or variant) class instance. Again a HWND and this pointer are both a reference that identifies a unique entity - MS Windows window or C++ object, but that are incompatible with each other. Bridging this gap is the job of another part of the glue code.  


All Answers

Answers by Expert:

Ask Experts


Ralph McArdell


I am a software developer with more than 15 years C++ experience and over 25 years experience developing a wide variety of applications for Windows NT/2000/XP, UNIX, Linux and other platforms. I can help with basic to advanced C++, C (although I do not write just-C much if at all these days so maybe ask in the C section about purely C matters), software development and many platform specific and system development problems.


My career started in the mid 1980s working as a batch process operator for the now defunct Inner London Education Authority, working on Prime mini computers. I then moved into the role of Programmer / Analyst, also on the Primes, then into technical support and finally into the micro computing section, using a variety of 16 and 8 bit machines. Following the demise of the ILEA I worked for a small company, now gone, called Hodos. I worked on a part task train simulator using C and the Intel DVI (Digital Video Interactive) - the hardware based predecessor to Indeo. Other projects included a CGI based train simulator (different goals to the first), and various other projects in C and Visual Basic (er, version 1 that is). When Hodos went into receivership I went freelance and finally managed to start working in C++. I initially had contracts working on train simulators (surprise) and multimedia - I worked on many of the Dorling Kindersley CD-ROM titles and wrote the screensaver games for the Wallace and Gromit Cracking Animator CD. My more recent contracts have been more traditionally IT based, working predominately in C++ on MS Windows NT, 2000. XP, Linux and UN*X. These projects have had wide ranging additional skill sets including system analysis and design, databases and SQL in various guises, C#, client server and remoting, cross porting applications between platforms and various client development processes. I have an interest in the development of the C++ core language and libraries and try to keep up with at least some of the papers on the ISO C++ Standard Committee site at


©2017 All rights reserved.

[an error occurred while processing this directive]