Qt and MFC comparisons

see on the Internet, take it with you to discuss. This article will not enumerate the advantages and disadvantages of Qt and MFC respectively.

The fact that I used QT before I used MFC could have affected my objectivity.

(MFC is more efficient, but a large number of Windows APIs and messaging mechanisms make it difficult to understand, not easy to use; QT package is good, easy-to-use and cross-platform, but less efficient)

The article starts from a pragmatic point of view: My boss gives me a description of the software and lets me develop it. Some of these I use QT to develop, while others I use MFC to develop.

MFC (Microsoft Foundation Class Library) is a class library designed specifically for Windows to develop a graphical user interface. MFC has more or less used an object-oriented approach to wrapping the Win32 API, and that's why these APIs are sometimes C + +, and sometimes a mix of the C, and even the C and C + +.

QT this C + + graphics library was developed by Trolltech in about 1994 years. It can run on Windows,mac OS X, Unix, and embedded systems like sharp Zaurus. QT is completely object-oriented.

Document/view model
MFC programming requires the use of document/view patterns and templates, which can be extremely difficult to program if not used. Also, the template sets a fixed structure, which is difficult to program if the desired structure is a structure not defined by the template. For example, divide a region so that two views (view) are displayed in two documents (document). Another common problem is that the template creates a view and cannot access (access) it, and the document has to do everything, but this often happens.

QT does not enforce the use of any design pattern. If you think it's appropriate, use Document/view without any problems. Do not use or have any problems.

Pseudo Object vs Real Object
Ultimately, the difference between Qt and MFC lies in its design.

The fundamental purpose of MFC is to access the packaged Windows API written in C language. This is not a good object-oriented design pattern, and in many places you have to provide a struct with a C language of 15 members, but only one of them is relevant to what you expect, or you must call your function with the old-fashioned arguments.

MFC also has a lot of confusing places, function names do not have any continuity. For example, if you create a graphical class, the class will not be created until you call creat (). However, for dialogs, you must wait until OnInitDialog () to create this object. Strangely enough, the name of the function that created the class became Oninitupdate (),...... You create a class yourself by calling it in their own way, and your program crashes.

For example, if you have a dialog containing a CEdit control, you cannot use GetWindowText () If you do not call DoModal (). Otherwise it will be a baffling failure. In short, MFC is full of confused things, and this error is difficult to debug.

Qt on the contrary, its architecture is clearly well-designed and object-oriented. QT thus maintains excellent consistency in naming, inheritance, and organization of classes. You just need to provide only one method parameter, just this one. There is also a strong coherence in how calls are invoked in different classes. The return value is also very logical. Everything has been achieved in a simple and powerful harmonious unity. Once you have used one of these classes, the other classes are comprehend by analogy because they are consistent.

In Qt, you can use the edit control to create your own qlineedit in C + + by creating a class. You can always access any method immediately, whether it is displayed or hidden. There is no mystery here, everything works in a simple way that you think.

Message loops
MFC is an event-driven architecture. To perform any action, you must respond to a specific message. That Windows sends to the application
The information is thousands, unfortunately, it is very difficult to clarify these sub-verbose messages, and the documentation on this is not a good solution to these problems.

The message mechanism of QT is built on the basis of signal () send and slot () acceptance. This mechanism is the core mechanism for establishing connections between objects. Any parameters can be passed with signal (). He has a very powerful function. You can pass the signal directly to the slot (), so you can clearly understand what is going to happen. The number of signals sent by a class is usually very small (4 or 5), and the documentation is very complete. It makes you feel like you're in control. The signal/slot mechanism is similar to the listener mechanism in Java, but this mechanism is more lightweight and more versatile.

Create an interface
MFC cannot create a dynamically variable size subwindow, and must re-manually modify the code to change the window's position (which explains why the dialog in Windows is not changeable), which is even more serious when the software is translating internationally. Because many countries need longer words and sentences to express the same meaning, it is necessary to re-modify their software for each language version.

In Qt, anything can be knocked out manually, because it's simple: to get a button, you can do that.

button = new Pushbutton ("ButtonName", myparentname);

If you want to invoke the execution of a broken code after you press a button, you can write:

Connect (button, SIGNAL (clicked ()), Qapp, SLOT (Action ()));

QT has a very simple, yet powerful layout mechanism, so that it is a waste of time not to use it.

QT also provides a graphical user tool, Qt Designer, which can be used to help build the user interface. You can modify the properties of any control you are using. Instead of placing them in a strict position, they can be organized perfectly through layout. The code generated by this tool is actually readable and understandable. The generated code is placed in a single file, and you can regenerate the user interface as many times as you want while programming.

Qt Designer allows you to accomplish a number of tasks that are not possible in MFC, such as using a pre-populated ListView to Use tab control with a different view on each tab.

Help documentation
When a user chooses a graphical development environment, it is important to decide whether the document is comprehensive or not. The help documentation for the visual Development Environment, MSDN (which is also sold separately) is very large and has 10 cdrom discs. He is all-encompassing and broad-ranging. But inevitably there is pays top academics, the theme is vague, the key information is not outstanding regret. Its links are also poorly designed, and it is difficult to jump from one class to its parent class or subclass and related classes through links. If you search for a keyword, whether it is Visual C + +, Visual J + +, visual Basic, as long as the information that contains these keywords is returned.

QT's document design is pretty good. You can get a glimpse of hosting on the doc.tolltech.com.

QT's documentation is complete and detailed, covering all aspects of QT, with only 18M. Each of the classes and methods are described in detail, the size of the exhaustive, examples of enrichment. Through the links provided by Trolltech company or the QT Assistant tool, you can easily jump from one class or method to another. The documentation also includes a beginner's tutorial and examples of some typical applications. FAQs and Mailing lists are also available for easy access through the Internet or user base. If you purchase a license, you will receive technical support from Trolltech company within one day.

In fact, QT's excellent help documentation has greatly reduced the chances of seeking outside help. One tenet of Tolltech company is that it is redundant to have such excellent QT product and its help documentation.

Unicode
With MFC, if you want to display Unicode, you must use special parameters when compiling the link (and change the entry for executable execution), you must precede each string with T, modify char to TCHAR, each string handler (strcpy (), StrDup () , strcat () ...) Change to a different function name. Even more annoying is that Unicode-enabled software cannot work with DLLs that do not support Unicode. This is a serious problem when developing with an external DLL, but you have no choice.

Using QT, strings are handled with qstring, which is inherently Unicode. No need to change anything. Do not add parameters at compile/link time, do not modify the code, only need to use qstring.

The Qsting class is powerful, you can use it extensively, and don't worry about Unicode issues. This makes converting to Unicode very convenient. Qsting provides functions that convert to char * and UTF8.

Obviously, MFC's CString design has a huge difference compared to the qstring design of QT. CString provides little functionality based on char *. The advantage of this is that the CString type can be used directly when a char * type is required. At first glance, this seems to be a merit, in fact, there is still a great flaw, in particular, you can directly modify char * instead of updating the class. This also has a lot of trouble when it turns into Unicode.

Instead, qstring stores the string internally in Unicode, providing char * functionality when needed. Char is rarely used, because the entire QT API responds to the qstring parameter in the form of text. Qstring also comes with many other features, such as automatic sharing of qstring content. This is a very powerful class and you will love to use it in many places.

Internationalization
Using MFC can be internationalized, but you need to put each string in a string table and use LoadString (Identifiet) everywhere in your code. Then convert these resources into the DLL, translate the string into the desired language, change the graphical interface, and then call the program to use this DLL. The whole process is so cumbersome that it is reaching. Consider things to the whole.

When using QT, you simply put the string in the function tr (), which is a little effort in program development. You can change the reference of a string directly in your code. A tool for Qt LINGUIST,QT that extracts all the strings to be translated and displays them in a friendly interface. This user interface is ideal for translating, using dictionaries, displaying string content, proper Unicode display, shortcut conflict detection, detection of untranslated strings, detection of string modifications, and full functionality. This software can be used by translators who do not have any programming experience. The software is published under the copyright of the GPL and can be modified according to your needs.
The subsequent document is saved in XML and is suitable for the principle of software reuse. Adding a new language version to the software simply produces a new file with Qt linguist.

Resources issues
Using MFC, part of the development process relies on "resources", and in many cases developers must use them. This can lead to the following consequences:

Out of visual Studio, it's hard to use other tools to complete your development.
The resource editor has only limited functionality, such as: it is not possible to change all properties through the dialog editor, some properties can be changed, and others cannot be changed. (Translator Note: There are also two examples of MFC shortcomings, but I feel that these are enough to explain the problem, temporarily abridged translation)
However, QT does not have the concept of resources, which solves the above mentioned problems. QT provides a script so that it can be programmed into your code. For interface design, Qt Designer creates a readable code.

Price
Once you have purchased Visual Studio, you will get the MFC SDK for free.

QT is free to get its GPL-compliant version on UNIX (note: The GPL version is now available for free on Windows). If you want to develop software that is unfair to open source code, you must purchase QT authorization. Under specific platforms, each developer buys a permanent license and receives one year of technical support. (Translator Note: After the purchase price and other issues to be deleted, because the price is not fixed, if in doubt, please go to the official website to check the price)

Release
When publishing MFC-based software, you must rely on MFC that exists on the client computer. But it's not safe, and it's also MFC42.dll, and you can get 3 different versions based on the same library. In general, you need to check if you have the correct version of MFC42.dll, and if not, upgrade it. But upgrading MFC42.dll will change the behavior of many software. This makes me feel uncomfortable, what if the user installs my software and causes the machine to crash?

QT does not have this risk because QT does not have the concept of "Upgrading the whole system" at all.

The feeling of MFC compared to QT does have a lot of shortcomings, but MFC's user base is huge. QT to short time to shake the status of MFC, or a little difficult

Qt and MFC comparisons