Incomplete comparison between GTK + and MFC

GTK + is not completely compared with MFC-Linux general technology-Linux programming and kernel information. The following is a detailed description. MFC has gradually declined, and GTK + is thriving. Here, we have no intention of falling down the rocks, hitting down the dogs with pain, turning down the MFC and Zun GTK +. You are using MFC and GTK +, and will not favor either of them. This comparison is entirely out of my personal understanding of the two. On the one hand, I just want to take notes on the rise, and on the other hand, my understanding of the two is limited.

1. Both are based on object-oriented design. Although MFC is written in C ++ and GTK + is written in C, the idea is object-oriented. GTK + uses the object mechanism of glib. The implementation of GTK + is a little complicated because it is written in C.

2. Both are message-driven. This is a common feature of the GUI system. messages can be reported by hardware, such as mouse events, keyboard events, and touch screens. Messages can also be generated by programs, for example, a window sends a message to another window. However, the two are not exactly the same. GTK + hangs on multiple file descriptors Through select, and can wait for multiple event sources at the same time, such as socket, sub-process exit, and kernel events, however, MFC can only be mounted to the Message Queue through GetMessage.

3. Neither of them is thread-safe, that is, only one thread can operate GUI resources. This problem is not big because most applications are single-threaded. They also provide some mechanisms for other threads to operate on GUI resources as necessary. In GTK +, you can use the idle function, and in MFC, you can use PostMessage (note: the native gui api of Win32 is thread-safe ).

4. GTK + integrates a series of basic function libraries with powerful functions. However, the battle of MFC is weak. Glib is the basic library of GTK +, which implements Common Containers and algorithms and isolates platform-related functions. Pango is a function library used by GTK + for text rendering. It controls the layout of different texts and submits the model drawing to font function libraries such as freetype for processing. Although MFC implements some containers, it is difficult to use a small number of containers. Besides packaging native GUI APIs, it does not provide many other functions, this name is not commensurate with Microsoft Foundation Class Library.

5. GTK + is cross-platform, while MFC is not. During design, GTK + considered portability. It organized the entire system according to the layered model. Glib encapsulated functions dependent on the OS platform and provided a set of abstract interfaces, different implementations are available on different platforms. GDK encapsulates functions dependent on input/output devices, such as obtaining Keyboard Events and displaying buffered output, and implements basic plotting functions. GTK + can run on almost all PC platforms, while MFC never considered portability. It is bound with Win32 GUI.

6. GTK + is small, while MFC is heavy. The executable files compiled by GTK + are about 3 m long. Although MFC itself is not large, it adds a considerable number of versions. MFC has the ansi version, unicode version, debug version, release version, and some combinations. If you fainted, it would be normal.

7. The use of GTK + is simple and the use of MFC is cumbersome. GTK + is easy to use. It is not difficult to write a GTK + application without the help of tools, in fact, most GTK + applications come out with a line of code. The use of MFC is too troublesome. It is hard to imagine that there is no help from the VC Wizard to write an MFC-based application. With the VC wizard, there are still a large number of programmers who say that MFC is difficult to use.

8. GTK + uses the signal mechanism to solve the coupling between the message source and the message target. MFC uses messages to hard encode the message source and message target. The advantage of Signal is that you do not need to know who the target is, and registration is done for anyone who cares about it. This publishing and subscription mechanism is the best way to decouple. The message of MFC must know who the target is, and bind the source and target together. MFC provides a set of document/view frameworks to implement functions similar to publishing and subscription. This is something the designers are proud of. As a result, it is too complicated to be understood, but it is criticized by developers.

9. GTK + uses the layout mechanism to dynamically calculate the coordinates and positions of subwindows and adapt to the changes in screen size. However, MFC requires hard encoding of the coordinates of subwindows. It is very difficult to adapt the results to screens with different resolutions. GTK + has two phases in the window layout. In the first stage, the parent window first queries the optimal size of the Child window, and in the second stage, the parent window calculates the actual size of the Child Window Based on its own size, the child window is adjusted based on the actual size.

10. GTK + uses the container mechanism to reasonably separate the role of the control. MFC does not have the container concept and it is difficult to implement recursive combination. In GTK +, almost all controls are containers and can accommodate any other controls. In MFC, only the top-level window is the container and can accommodate other child controls. The concept of container has a huge impact on code reuse. Here are two examples: one is BitmapButton, which is a combination of GtkImage and GtkLabel in GTK +, in MFC, images and text must be drawn by yourself. The GtkImage and GtkLabel of the former can be reused in many places, and the subsequent code and event processing code can only be used by themselves. The second is the list box. In GTK +, it is just a container. You can put the editor, drop-down box, and any other controls you want into it. In MFC, even if you only implement a list box with different appearances, you must use a self-painting method. code reuse is very difficult. It is even more troublesome to add other controls to the list box, some unusual means are required.

11. GTK + uses the container mechanism to prioritize combination rather than inheritance, in line with modern design principles. MFC enforces inheritance, which is difficult to use and tightly coupled. GTK + applications do not need to inherit any windows. The MFC application must inherit the dialog box or other top-level windows. Although the intermediary mode can be used to centralize the interaction between controls in the top-level windows, it is still very troublesome to inherit the controls.