Comparison of Visual C and Delphi / C Builder of: milk vetch JasonCrazy@sina.com "Visual C and Delphi / C Builder comparison of" this topic perhaps a little bored, but since there are so many people online in debate This topic may not be all worthless. I think your website "Academic Atmosphere" is relatively strong, and people are also friendly in the new chat room. (Maybe because everyone will come together for the same goal. ^ _ ^) I will send this one may have controversial Dongdong. This article welcomes discussion, also welcomes criticism, from language to content. The text often sees a friend in the 9CBS and other forum posts. Asking Visual C and C Builder These 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. Compare it from their ease of use. VC has a series of tools such as ClassWizard, SourceBrowser, and Visual SourceSafe, Visual Modeler, etc., which is easy to use. (VC self-modeling tool Visual Modeler, may illustrate that it is an engineering-level development platform, different from C Builder.) The MSDN "developer's encyclopedia" it belongs is to let you "I haven't found it, only I can't think of". And its small functionality such as AutoComplete is also more than the C Builder. Although the new version of C Builder also provides this feature, it has to wait for a few seconds, sometimes you will stop the mouse in one place, and wait for the hard drive to ring a few seconds, this is 566MHz Celeron II. Don't laugh at me trivial, sometimes the maturity and ease of development tools, it is from these small places.
C Builder acts as a RAD tool, it should emphasize ease of use. However, it is still not mature than VC. This should not be. Let's take a look at their portability. Inprise is developing C Builder and Delphi's Linux version, the code is Kylix. Perhaps through Kylix, a Windows program written in a VCL architecture is possible to transfer to Linux. But this is just possible. Because it is not good to work in the current Inprise compatibility. C Builder can compile VC programs and you have to use Microsoft to write MFC using standard methods, and its own compatibility between its own versions is not very good. Low versions of C Builder cannot use high versions of VCL components (which don't say it), and high version of C Builder can't use low version of VCL components. It's really this, I rarely see that the software is not compatible. If Windows 98 cannot run 95 programs, Windows 95 cannot run 3.x, Win 3.x cannot run the DOS program, do you still use Windows? If it is not the other of C Builder too good, the light is not compatible, it is enough to let me abandon it. Moreover, although C Builder can compile Delphi's Object Pascal code by bundled compilers, C Builder cannot use VCL components developed by Delphi. So a component has a different versions of these different versions of the For D1 / D2 / D3 / D4 / D5 / C1 / C3 / C5, and the upgrade of the C Builder may also increase. I hope that Inprise can solve the compatibility problem of the same brother. And Microsoft's VC has no such problem. The program of MFC 1.0 can also be compiled under VC6.0 without barrier. Let's take a look at their prospects. In fact, the advancement of technology is many times. At first, Borland's Turbo C and Borland C were almost unique. Microsoft's Quick C (now someone knows this product?) And Microsoft C / C have never become mainstream. But how many years is Borland C ? Soon, I was pressed by the newly rising Microsoft Visual C / C . Now C Builder has a post-hosted situation. If stability is improved, BUG is less, and there is hope to become mainstream. But the overall strength of Inprise is not Microsoft, which is not a context. From the Release Notes of C Builder 5, you can see the size and quality of their help documents. (Which other product helps "and MSDN ratio?) Inprise should learn from Netscape, do not let C Builder become the second Netscape Communicator. (Communicator is also a leading technology, and even occupied most browser markets, but it seems to be lack of strength, and there are many bugs in 6.0 pr1, 2, and now I've can't do it.) C builder is the flagship of Inprise One of the products, the prospect should be more optimistic, and Inprise has been entered to Linux, and Microsoft has not moved. Is it necessary to go to Linux? This emerging market? It seems that their attitude towards Linux has a sluggish response to the Internet a few years ago. But later ... Hey, I hope that Inprise does not step back to Netscape. C Builder is a very promising development tool.
