Mfc? Vcl?

Recently online debate VC and DELPHI/BCB pros and cons of a lot of friends (in fact, not recently, has been a lot), in fact, most of the differences in the MFC and VCL two sets of Class library choice. Do you have any idea what these two sets of libraries, or application Framework (hereinafter referred to as AF), really mean?
For a set of AF, the biggest difference with a set of class library classes, is that it is a complete set of built-in framework, style, structure has been done, you have to obey, and the class library is take doctrine, the ideal realm should be the assembly of components (Component), For example, the Standard Template Library STL is a final example. AF is likely to have several major elements, Hou Sir's masterpiece, "Easy to learn MFC" in detail the six key technologies of MFC, which is more important: the operation of type identification (RTTI), Dynamic Generation (Creation), Permanent Survival/serialization (perisitance/ serialization) and message map (msg Mapping), there is also a thread-safe that is not discussed by the Sir-in-Waiting (thread Safety). About these questions, I and Myan elder brother once in e-mail a little discussion, the following separately talk about my ideas.

First of all, now popular AF is basically a single inheritance, the reason why, let me guess, technically, cobject/tobject/java.lang.object can be rtti or related information, can only determine the parent class, if void* and multiple inheritance obviously not , of course, may be related to the problem of multiple inheritance and the embarrassment of the rhombus structure (see thinking in C + + for multi-inheritance mi); From a business perspective, no one wants users to use other people's AF as a limit. Of course, a single inheritance is a very, very huge inheritance tree, so Java is now becoming more and more difficult to learn, just as the JDK is getting bloated and bulky.

Rtti is the ability to compare new languages, such as the new C + + standard, Object Pascal (DELPHI) and Java, mainly dyanmic cast, which requires type checking and throws an exception (exception, some people like to call "exception" ), you need to output some diagnostic information related to the class. C + + 's Rtti is the simplest, can only get the class name and related inheritance information, and Object Pascal and Java are more complex, even can be either the property name and the method name. As the C + + form of AF, the standard C + + provides information is obviously not enough, so MFC playing independently made a set of their own rtti, and then become the ANTI-MFC fighters crucified object.
By the way I help Microsoft defense, in fact, think carefully should understand Microsoft's frustration: the C + + standard only stipulates that typeid can obtain the class name and related information, but the format of the output, binary organization format does not have any provisions, and typeid is not entirely the compiler internal implementation, Also relies on the structure defined in the header file <typeinfo>, so chaos. such as a Class A, the Borland compiler on the class name is "a", on the Microsoft/intel compiler is "Class A", on the GCC is "1 a" (if it is a template class, gcc may even be garbled), And the structure of storage typeinfo is actually different. and MFC is by Microsoft, Borland, Synamtec, watcom, and so many compilers use and dynamically connected to the MFCxx.dll, if the standard C + + Rtti and exception, improper machine is strange. So how much have you seen using standard C + + as Rtti af? More popular such as QT (KDE) and CodeGuru can be seen on the VCF (Visual Component framework,c++ written), are self-made system of RTTI. and Object Pascal (DELPHI) and Java are only developed by one company, of course, there is no problem of C + +.
Since AF is basically a single inheritance, it is possible to get the name of the parent class. MFC provides the RTTI is actually similar to the standard C + +, mainly to obtain the class name and a iskindof (standard C + + can be used dynamic_cast test), and the VCL and JDK Rtti can get all the interface and all the method information , which is one of sun's arguments for attacking C + +. Actually want to laugh, first rtti is the simplest of all features, is nothing more than a record of some information just, do not remember it is finished? For example, MFC is the use of macros (macro, you do not like to call it "macro" it?) The way to record their own rtti, and CodeGuru on that VCF further, with a macro record of all method and property information, this is the same as VCL/JDK. and QT (KDE) more simply, directly with the MOC to help you write. Second, Rtti too much leads to bloat, and is it useful to know all the method names? It is for the IDE, but not much benefit to the user.

Dynamic generation and permanent survival/serialization standard C + + is not provided, it is said to have a one in the STL, and later did not have the following. Of course, MFC also use a macro is simulated, but Serialize will trouble you to write your own. VCL is implemented by Readcomponent and writecomponent in the Tstream class, and it is automatic and does not have to be written as MFC itself. Why? Does VCL have an attribute (property)? In fact, it is to write all the contents of the property in. If the property as a smart pointer, in fact, smart pointer initialization can be registered, and then can provide Rtti and automatic serialization. From this point of view, VCL is really simple, of course, C + + write a smart pointer can do.

The message map does not really say too much, the direct mapping of macros and the delegation model of VCL are not far from the principle. The way of VCL is very direct, a little efficiency loss, the detailed discussion of MFC way to see Hou Sir's book on the line. I would like to say a bit more about QT (KDE) used by the Signal-slot model, very interesting, direct Connect is OK, but unfortunately, this is based on the expansion of C + + (said the harsh point of the C + + standard wanton trample) on the need to use its MOC pretreatment.

    thread safety is a chronic problem. C from UNIX to C + + molding, UNIX is still a process-based concept, and there is no thread shadow. Just to the GUI era, the background processing of the front desk response (such as the handling of mouse actions) The problem of the CPU is increasingly serious, now almost all the OS has a thread concept, unfortunately, too many standards, such as POSIX and Windows threading model is too far, resulting in the writing program and platform correlation is very large, c+ The + standard does not respond to this. The threading model in MFC is the implementation of WIN32, mainly the key code snippet (Critical section) and some kernel objects (event, semaphore, etc.), and the VCL mainly implements the Critical sections and the semaphore (event). In terms of synchronization, due to MFC's semi-encapsulation (MFC is often scolded with the API is too large) behold this responsibility to throw the API, the problem is not, and the VCL is miserable, other threads can not interfere with the main thread of the work, can only apply, and then in fact is a single-threaded way in the work, sometimes really better than not Java bragging threads do not have to mention, borrowed Myan e-mail in a word, "Andrei and Dinkumware Pete Becker said, Java multithreading is for people who do not program, Toy-like." The

    a summary of that.
    MFC The entire structure is implemented mainly by macros, a bunch of headaches, and the compiler does not have type-checking macros. Of course, I believe that Microsoft's original intention is to let you use rather than let you understand these macros. The implementation of VCL is mainly derived from Borland's expansion of Object Pascal, such as __closure extension of C + + class member function pointers, __published increased __property and Rtti. It seems that MFC is cumbersome, but the compatibility is good (how can it be used on so many compilers?). And the VCL looks very concise, but this wanton expansion brings the consequences of no portability, so the VCL is not as widely used in various compilers as MFC.
    in terms of thinking, MFC is mainly Document/view architecture, too restrictive, which is not as good as the component of the VCL random combination. However, it is necessary to mention that many people think that the VCL package is higher level, more abstract than MFC, so better, the most direct example is the Tcanvas class of VCL and the comparison of MFC's CDC class. And my view is that, although it is AF, but the relationship between class and class should be able to cooperate, coupling, dependence and as small as possible, so that is the real component, can be arbitrarily combined with the building block type component. The component combination in VCL is only for the class in the VCL, there is no connection with the outside world, and the dependency between the classes is too large, and the MFC semi-encapsulation feature makes MFC do well in this respect.

Finally I have to say, I hate AF, because I hate that huge inheritance tree, I hate the kind of frame structure that suppresses freedom. STL is doing very well in this respect, and Microsoft and Borland are moving forward with another set of class libraries, ATL and CLX. Of course, ATL is still adhering to Microsoft's consistent purpose of non-cross-platform, but the writing is really beautiful, completely threw MFC, full use of C + + unique template and multi-inheritance technology, light weight. Forgive my brother is really caishuxueqian, dare not to add evaluation, you are interested to see more Pan masterpiece, and CLX from Borland to provide some of the documents, the structure and VCL seems to be no big difference, or old-fashioned deep inheritance tree, of course, this with Borland do not want to put object Pascal is related to the axis of its product, while Object Pascal does not have the unique capabilities of C + +.

Opinion, I hope you will express your views.

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

Mfc? Vcl?