Visual C ++ uses the framework MFC, but many people do not know it very well. In fact, this is not difficult to understand. MFC is actually provided by Microsoft, it is a framework and engine used to write applications in the C ++ environment to better work for Visual C ++.
This is an advantage, but it is interesting that, because of this, Microsoft must consider minimizing the changes to the language itself when writing MFC, and put the effort at the source code level, in order to support ANSI and other standards as much as possible, the result is that the MFC encapsulation is complex and not intuitive.
Too many comments with vague macro definitions and meanings that are automatically generated and cannot be modified make MFC and VC daunting for many new users and dare not "launch" for further study. The Object Pascal is almost Inprise "dedicated" and does not need to consider the "standard" issue. Therefore, when writing VCL, Inprise focuses on the structure and performance, result The language and framework work well. The VCL framework has a clear structure and the VCL code is very readable. Many people say that Delphi is easier to use. There is no white lunch in the world. Do you want industrial standards? Do you want portability? (for more information about portability and compatibility, see the following )? So please face the "tianshu"-level code of MFC.
Compilation and connection: The Need For Speed
Another difference brought about by different languages is the speed of compilation and connection and the speed of execution. Delphi's compilation and connection speed are dozens of times faster than VC. Even if you enable the Incremental Link option of VC, the compilation and connection speed of Delphi is several times faster than that of VC. It doesn't mean that Microsoft's compiler doesn't work. This is determined by the complexity of C ++.
Template processing, preprocessing, and macro expansion are time-consuming. Didn't we mention that Object Pascal has no templates, preprocessing, and Macros? This is a disadvantage, but one advantage is that the compilation speed is extremely fast. As for the compiled binary code, the execution speed of Delphi and VC is not significantly different when the same optimization option is enabled.
To overcome Compilation speed problems, C ++ compilers generally need enhanced connectors and preprocessing mechanisms. However, the preprocessing mechanism still has several problems:
1) the breakpoint line for program debugging may be different from the code line;
2) The latest code information is not integrated;
3) logic that is prone to errors;
4) An error similar to "Unexpected End of File" is easily generated because the File header is read incorrectly.
One of the two compilers is that they can recognize useless "dead" code, such as a useless function. The compiled program does not contain the redundant information. Delphi is doing better in this regard. It allows you to visually display in the editor that the line of code is "active" and that line of code is "dead. In this way, you can sort out the most concise code.
After compilation, Delphi will display a small blue dot on the left to indicate that this line of code is "active. Visual C ++ cannot do this. After Delphi compilation, the executable file must have at least kb. If VCL is not used, only WinAPI is used, and the file size will be greatly reduced) however, Visual C ++ programming uses only dozens of K executable files compiled by MFC, this is mainly because Microsoft has included the system Runtime Library in the Windows system. Borland Once negotiated this interface with Microsoft, but Microsoft is reluctant to disclose the advantages of the operating system ).
Similarly, database programs developed using BDE must include 3-5 MB of additional system files, which is very uncoordinated. It is very interesting that Delphi can use the OBJ file created by C ++ Builder, but its usage is limited. Finally, the error information DURING Visual C ++ compilation and connection is more detailed and specific than Delphi. This is especially true when using ATL for development.
Application Framework: MFC? Is KFC popular?
An Application Frame is also called an object framework. The framework used by Visual C ++ is MFC. MFC is not just a class library that people generally understand (similarly, Delphi's VCL is not just a control library, although its name is "visual control library "). If you select MFC, you also choose a program structure and a programming style.
MFC came into being as early as the Windows 3. x era, and Visual C ++ was still 16-bit. After years of continuous supplement and improvement, MFC has become very mature. However, because the prototype appeared earlier, MFC lags behind the VCL era.
Although Microsoft has not stopped the update of MFC, I often read articles such as "If Windows is not outdated, MFC will not be outdated", but it is like Inprise (formerly Borland) similar to the fade-out of the OWL framework, the fade-out of MFC is also a matter of time. In fact, MFC is the product of the same era as OWL.
If OWL is no longer there, how can MFC not "live in danger? If MFC remains young, Microsoft developers will not "launch ATL-based WTL without authorization. Of course, WTL cannot be compared with MFC. It is not a framework officially supported by Microsoft, and its encapsulation functions are quite limited. However, at least the shortcomings of MFC exist.
We believe that the delegated model is the encapsulation mechanism for Windows messages, which best reflects the advancement of an application framework. It is unnecessary to encapsulate Windows APIs. Similar to each other, there is no technical content. If you are happy, you can also write a class library for encapsulation. However, encapsulation of the Windows message driver mechanism is not that easy.
The most natural encapsulation method is the use of virtual member functions. If you want to respond to a message, reload the corresponding virtual function. To my surprise, MFC uses the macro definition method of "old. The advantage of using the macro definition method is that the system overhead of the virtual function VTable is saved (because of the many message types in Windows, the overhead is not too small ).
However, the disadvantage is that the ing is not intuitive. For MFC, it is "too intuitive. Although its message ing code is visible, it is "recommended ". Fortunately, the VC ClassWizard can automatically generate message ing code, which is easy to use. However, compared with the commissioned model of VCL, the MFC ing method is far behind. Because Delphi's Object Pascal does not have a "Standard burden", the language introduces new features such as components, event processing, and attributes. The source code generated by Kung Fu is very concise at the compiler level.
It seems that VC is "accommodating the framework to the language", while Delphi is "accommodating the language to the framework ". I would like to give an example of encapsulation of string operations to illustrate the advantages and disadvantages of MFC and VCL. In MFC, The CStringList class provides functions such as adding, obtaining, and deleting. However, the TStringList class of VCL provides functions such as sorting, reading strings separated by commas, and streaming input and output.
However, for the same string replacement function, the StringReplace of VCL is 2-3 times slower than the CString: Replace of MFC. In general, the encapsulation of VCL is higher and more abstract than that of MFC, but the inevitable problem is that the execution efficiency of some parts is slightly lower than that of MFC. This is like a low-level language (such as assembly) with a higher execution efficiency than a high-level language (such as Basic), but a lower programming efficiency. You can't have both the fish and the bear's paw.
Another advantage of VCL over MFC is its support for exception handling, but its major disadvantage is its poor support for multithreading. Most VCL is not optimized for multithreading. Although VCL provides a class to simplify multi-thread operations, it is simple to use worker threads.
If the thread needs to deal with the interface, things will become troublesome, because apart from the main thread of the application, no thread can access any visible C ++ component. You have to use the Synchronize method to wait for the main thread to process its messages, and then access the Visual C ++ component in the main thread. However, MFC does not have such restrictions.
- How to Write C ++ project development and project plan correctly
- Summary Notes on learning and exploring C ++ library functions
- In-depth demonstration of high security of C ++
- Describes in detail how to accurately Write C ++ languages.
- In-depth demonstration of high security of C ++