Why does MFC use message ing tables instead of virtual functions?

This is the most frequently asked question during windows development interviews and is also a very deep question.
Two posts have profound discussions on this issue:
Http://topic.csdn.net/u/20090822/16/4cf5d189-0e5e-41ff-9ba3-c7eaf2f6da74.html
Http://topic.csdn.net/u/20090316/22/8b067591-6a17-4970-b224-41ab589294b3.html

Statement 1:
Virtual function implementation occupies a large amount of memory
Hou Jie said in "getting down to MFC" that Microsoft uses message ing instead of virtual functions because of the cost of virtual function space. The current version of mfc2.0 was released in 92 years, with only a few MB of PC memory. The size of a virtual table of a class is the number of virtual functions * the size of a pointer.
Suppose there are 200 common messages in windows, so the cwnd virtual table has 200*4 bytes = 800 bytes.

All the derived classes of the cwnd class copy a virtual table vtable of the cwnd class, and then add the following header of the virtual table of the cwnd class to their own virtual functions.
(It is not reliable to say that the derived classes of the cwnd class can share the virtual tables of the cwnd class. Because the virtual function value of the derived class is added to the end of the virtual function table item of the base class. If cwnd derives cwndchilda and cwndchildb, and both of them have their own virtual functions, then they are added to the back of the cwnd class. Isn't it a conflict ?)

That is, all the derived classes of the cwnd class in the system must bear the cost of bytes. If 100 classes are derived from cwnd, the cost is 800*100 bytes, that is, 80 KB. This was a huge memory consumption when the memory was very tight at the time! Note the following:Vtable is bound with a class, rather than a Class Object (also called a class instance). The class instance only adds a pointer to the vtable of the class.That is to say, if you have 100 cwnd Derived classes, even if you have generated 100000 derived class instances, the vtable occupies 80 KB of memory.

It seems that in the current environment, MFC did not use virtual functions, and the memory is indeed a consideration.
But now, the memory consumption is really insignificant! That is to say, if we re-design the message mechanism of MFC and do not use virtual functions, it is not because of the space waste of virtual functions.

Conclusion: This statement is reliable.

Statement 2:
Message ing is more efficient than virtual functions.
Because there are so many message IDs, if you find the corresponding message processing function, switch is indispensable! (Hash? Oh, indeed, it is possible, but does it happen in MFC? I don't know how to do it in MFC)
In MFC, message ing is used instead of virtual functions, because there are many messages. If virtual functions are used, you need to define a virtual function for each message, when distributing a message,ProgramYou need to determine the message one by one, find the appropriate branch, and then call the corresponding virtual function. Normally, the application does not need to respond to too many messages, the message ing method only needs to determine the messages that the program wants to respond to, so the overhead is low.
That is to say, when MFC uses message ing instead of virtual functions, it considers the message response mechanism.Message ing allows you to only implement the messages you are interested in, so that the switch can be faster.

However, when a system message that is not of your own interest comes, you need to traverse the Message Network and search for the base class layer by layer until you find the corresponding message processing function! This is a waste of time! Maybe this is rare. Otherwise, the message response time of message ing is not faster than that of the virtual function! Because Virtual functions only need to be traversed at most once, and if Hash technology can be used, it is faster!
If most messages are system messages, the iterative message search function of message ing is not faster than the switch of the virtual function!
PS: Here is a simple simulation experiment comparing message ing mechanism and virtual function mechanism efficiency.
Http://blog.csdn.net/hjsunj/archive/2008/01/10/2034314.aspx

Conclusion: This statement is unreliable!

Statement 3:
For future scalability. Compatible with new system-level messages.

I am not very clear about the original intention of MS to design message ing, but I feel it is easy to focus more on adding new messages, rather than saving memory.
If we use the virtual function mechanism for implementation, I am afraid we must define a virtual function in the base class for every possible message, the first difficulty is that you cannot guess what messages will appear in the future, or determine what kind of function prototype is required to define the virtual function. It is relatively easy to solve this problem by using message ing, because it will be determined by future programmers how their messages should be processed.
Supports message ing for new messages in the system. To support virtual functions, you need to change the base class to add virtual functions.
For custom messages, message ing and virtual functions can be well supported.
How does the virtual function support custom messages?
Custom messages do not need to be added to the base class. You can add a virtual function (onmessage (XXX) to the base class, and then implement a class for custom messages. Use switch to convert the class to the corresponding virtual function call, instead of passing your own messages to the base class.

Conclusion: This statement is reliable.