MFC? VCL?

Recently, many friends have argued about the advantages and disadvantages of VC and Delphi/BCB on the Internet (in fact, not recently, there have been many). In fact, most of the differences are in the choice of the two class libraries of MFC and VCL. I don't know how you understand these two class libraries, or application framework (AF?
For a set of AF, the biggest difference from a set of class libraries is that it is a complete set of frameworks that have been built, and the style and structure are all done well, you have to follow it, the class library focuses on the concept of "tailism". The ideal realm should be the component that can be assembled. For example, the standard template library STL is the final example. AF has several major elements. Hou sir's masterpiece, "Let's get to the bottom of MFC", discusses in detail the six key technologies of MFC, among which the most important is: rtti), dynamic generation (dynamic creation), permanent survival/serialization (perisitance/serialization) and message mapping, there is also a thread safety (thread safety) not discussed by Sir ). On these questions, I and myan brother once discussed a little in E-MAIL, below respectively to discuss some of my ideas.

First of all, the popular af basically adopts single inheritance. The reason is, technically speaking, cobject/tobject/Java. lang. the object can uniquely identify the parent class through rtti or related information. If void * and multi-inheritance obviously do not work, of course, it may be related to the trouble of Multi-inheritance and the embarrassment of the diamond structure (For details, refer to the discussion on multi-inheritance MI in thinking C ++); from a business perspective, no one is willing to use another user's Af. This opportunity is a limitation. Of course, single inheritance brings about a very huge inheritance tree, so Java is becoming increasingly difficult to learn, just as JDK is becoming increasingly bloated.

Rtti is the capability provided by newer languages, such as the new C ++ standard, Object Pascal (Delphi) and Java, mainly because dyanmic cast needs to perform type checks and throw exceptions (exception, some people also like "exceptions") and need to output some diagnostic information related to the class. Among them, the rtti of C ++ is the simplest, and only the class name and related inheritance information can be obtained. The Object Pascal and Java are more complex, or even the attribute name and method name can be used. As a C ++-style AF, the information provided by the Standard C ++ is obviously insufficient. Therefore, MFC developed its own rtti and became the target of all anti-MFC fighters.
By the way, I will defend Microsoft. In fact, I should think carefully and understand Microsoft's helplessness: The C ++ standard only specifies that typeid can obtain the class name and related information, however, there are no rules on the output format and binary organization format. typeid is not completely implemented in the compiler, but also depends on the structure defined in the header file <typeinfo>. For example, if a Class A is obtained from Borland's compiler, the class name is "A" and the Microsoft/Intel compiler is "Class ", it is "1A" on GCC (if it is a template class, GCC may even be garbled), and the structure of the storage typeinfo is still different. However, MFC is used by Microsoft, Borland, synamtec, Watcom, and many other compilers and dynamically connects to mfcxx. dll. If the standard C ++ rtti and exception are used, it is strange to use an improper machine. So how many af servers using standard C ++ as rtti have you seen? Popular VCF (written by visual component framework and C ++) such as QT (KDE) and codeguru are self-built rtti. Object Pascal (Delphi) and Java are both developed by only one company. Of course, the C ++ issue does not exist.
Because the current af basically uses single inheritance, you can obtain the name of the parent class. The rtti provided by MFC is similar to the Standard C ++. It mainly obtains the class name and an iskindof (the dynamic_cast test can be used in the standard C ++ ), both VCL and JDK rtti can obtain information about all interfaces and methods, which is also one of Sun's arguments for attacking C ++. In fact, it is funny. First of all, rtti is the simplest of all features. It is nothing more than recording some information. Can you just remember it yourself? For example, MFC uses macros (macro, you don't like to call it a "huge collection", right ?) While the VCF on codeguru goes further, recording all method and property information with a macro, which is the same as VCL/JDK. While QT (KDE) is simpler and can be written directly using MOC. Secondly, too many rtti leads to bloated, and do you know All method names are useful? It is only used for IDE, but it is not very good for users.

The standard C ++ for dynamic generation and permanent survival/serialization is not provided. It is said that a standard C ++ has to be created in STL and has not been provided below. Of course, MFC also uses macros for simulation, but serialize requires you to write it yourself. VCL is implemented through readcomponent and writecomponent in the tstream class, and it is quite automatic and does not need to be written like MFC. Why? Isn't VCL a property? In fact, all the property content is written in. If you think of property as a smart pointer, you can register the smart pointer during initialization, and then provide rtti and automatic serialization. From this point of view, VCL is indeed simpler, and C ++ can also write a smart pointer.

In fact, there are not many message ing. The direct ing of macros is not far from the principle of the VCL delegate model. The VCL method is very direct, with a slight loss of efficiency. The detailed discussion of the MFC method is just a look at Hou sir's book. I 'd like to say a little more about the signal-slot model used by QT (KDE). It's very interesting. Connect is OK, but unfortunately, this is based on the expansion of C ++ (the ugly point is to trample on the C ++ standard) and needs to be preprocessed using its MOC.

The problem of thread security is too difficult. When C is taken from UNIX to C ++, there is no thread shadow in UNIX. In the GUI era, the CPU competition between background processing and front-end response (such as the processing of mouse Actions) is becoming increasingly serious. Almost all operating systems now have the concept of threads, but unfortunately there are too many standards, for example, the POSIX and Windows Thread models are too far behind each other, resulting in a high correlation between the written Program and the platform. The C ++ standard does not respond to this. The thread model in MFC is Win32 implementation, mainly including the key code segments (critical sections) and some kernel objects (events, semaphore, etc ), VCL also implements the critical section and event ). In terms of synchronization, due to the semi-encapsulation of MFC (the relationship between the MFC and the API is too large often), this responsibility is thrown to the API, which is not a big problem; VCL is miserable, other threads cannot interfere with the work of the main thread at all. They can only apply and work in the form of a single thread. Sometimes they are not as good as they are. I don't need to mention the thread I boast of Java. In myan's e-mail, "Andrei and dinkumware's Pete Becker said that Java's multithreading is intended for non-programmers, toy-like."

Summary.
The implementation of the entire structure of MFC mainly relies on macros, which are a bunch of headaches and cannot make the compiler perform type checks. Of course, I believe Microsoft's original intention is to allow you to understand these macros only. The implementation of VCL mainly comes from Borland's extension of Object Pascal. For example, _ closure extends the class member function pointer of C ++, _ property added by published and _ classid added by rtti. It seems that MFC seems complicated, but its compatibility is quite good (or how can it be used in so many compilers ?); VCL looks simple, but the consequence of this arbitrary expansion is that there is no portability, so VCL is not as widely used in various compilers as MFC.
In terms of thinking, MFC mainly refers to the document/view architecture, which is too restrictive. This is not as beautiful as the random combination of VCL component. However, it is worth mentioning that many people think that VCL Encapsulation has a higher level and is more abstract than MFC, so it is better. The most direct example is the comparison between the TCanvas class of VCL and the CDC class of MFC. In my opinion, although it is Af, the relationship between the last class and the class should be able to cooperate collaboratively, and the coupling and dependency should be as small as possible. This is the true component, modular component that can be freely combined. The component combination in VCL is only applicable to classes in VCL, which has no relationship with the outside world and has a large dependency between classes, however, the half-encapsulation feature of MFC makes MFC very good in this regard.

Finally, I have to say that I hate af because I hate the huge inheritance tree and the framework structure that suppresses freedom. STL is doing very well in this respect, while Microsoft and Borland are also moving forward, with another class library, ATL and clx respectively. Of course, ATL still adheres to the principle that Microsoft does not use cross-platform platforms, but it is very beautiful. It completely throws MFC and makes full use of the unique templates and multi-inheritance technology of c ++, Which is lightweight. Sorry, my younger brother is really a beginner, and I am not afraid to comment on it. If you are interested, take a look at Pan Daxia's masterpiece. clx seems to have no major difference between the structure and VCL from some Borland documents, it's still the old deep inheritance tree. Of course this is related to Borland's need to regard Object Pascal as the central axis of its product, and Object Pascal does not have the unique capabilities of C ++.

I hope you can express your views.

Original article: http://www.newasp.net/tech/program/20108.html