I often see friends who have posts in the forum. Ask Visual C and C Builder. Two heavyweight development tools are excellent (more is to ask Visual C and Delphi. " This article is trying to compare them from the technical level, ease of use, stability, and development prospects.
Since Delphi and C Builder are the INPRISE products, share integrated development interface (IDE), and use the same set of VCL frameworks (this most important), their debuggers, PVCS / TeamSource team development support, database engine and Other advanced features of integration in the Enterprise Edition are the same, so this article will be classified with C Builder into the "same display". I saw some Delphi programmers to think that C Builder is relatively close, this is a misunderstanding. In fact, Delphi and C Builder differ in except for the language used, the rest is almost the same. In order to avoid topics to C languages and Object Pascal Languages (ie, the language used by Delphi), the following main comparison analysis of Visual C and C Builder.
First, compare from their application framework (Application Frame, sometimes referred to as an object frame). The framework used by Visual C is MFC. The MFC is not only a class library that people usually understand. (Similarly, the concept of VCLs used by Delphi and C Builder is not just a control library.) If you choose MFC, a program structure is selected, a programming style. The MFC appeared early in the era of Windows 3.x, and the Visual C of the time was 16 bits. After these years, the MFC is already very mature. However, because the prototypes have been earlier, the MFC has been behind the VCL behind the VCL. Although Microsoft's update to MFC does not stop, I often read "As long as Windows, MFC will not overtime", but like the OWL framework of Inprise (original Borland), MFC It is also a morning and evening. If the MFC youth is always stationed, Microsoft's developers will not "privately" to develop ATL-based WTL. Of course, the status of the WTL cannot be compared with the MFC, which is not a framework for Microsoft's official support, and the functionality of the package is quite limited. However, at least it is also lined out of the lack of MFC.
I thought that the advancement of an application framework is its entrustment model, that is, the package mechanism of Windows messages. (Don't say it for Windows API. Datong, there is no technical content. If you are happy, you can write a class library to encapsulate. But you are not so easy to pack the Windows message driver mechanism.) Natural package is a virtual member function. If you want to respond to a message, you will overreload the corresponding virtual function. But I am unexpected, MFC uses "ancient" macro definition method. The advantage of using macro definition methods is to save system overhead of virtual function VTABLE. (Due to a lot of WINDOWS, the overhead is not too small.) However, the shortcomings brought about the map is not intuitive. Good ClassWizard, which is better than the new version of the VC, can automatically generate a message map code, and it is still more convenient to use. However, the mapping method of the MFC is too late compared to the VCL's entrustment model. The C Builder has expanded the C language to introduce new features such as components, event processing, attributes. Since Kung Fu is done in the compiler level, the source code generated is very simple. However, due to the expanded non-standard characteristics, the source code of C Builder using VCL cannot be compiled by other compiler. The MFC's work is done in the source code level, although the message mapping code is more complicated and not intuitive, but the compatibility is very good. As long as you have the source code of the MFC library (with the VC Enterprise Edition CD), your MFC program is theoretically compiled with any ANSI standard compiler. C Builder 3 or higher can be originally compiled directly to the Visual C program. Many people think this is the compatibility of C Builder. It is actually a large extent to be compatible with MFC. Microsoft's hard work is hard to write MFC, but it is easy to manufacture. I don't know why they do? Because C Builder extends language, VC cannot compile C Builder program. It seems that VC is to be lost to C Builder in this regard. And the components, attributes, and the like supported by the VCL are the lack of MFC. Although VC can also support components, it is not as simple as VCLs through Mr. APPWIZARD. Many people use C Builder to rush on the container on the control panel, and the VC can use a lot of components (maybe not less C Builder), but because it is inconvenient, the RAD programmer is not Attractive. The C Builder's VCL is an exception handling than the other features of the MFC of Visual C . But the ridicitization is that its exception handling code has bugs, sometimes unprecedented. I don't know if there is any correction in the latest version. The frame MFC of the VC is not a place. After that, so many years of development and improvement, the MFC function is very comprehensive, and it is very stable, and BUG is very small. Among them, you may have more bugs. And there are third-party specialized tools to help you avoid these bugs. This is not easy to do this. Don't underestimate this, many professional programmers are to choose VC for this. The BUG of C Builder's VCL is relatively, and some example programs that it bring themselves have errors. It seems that inprise has a long way to go.
