VISUAL C++,DELPHI,C++Build

[boneheat]

我认为讨论一下VISUAL C++和DELPHI是很有必要的，两种平台同样是世界上最优秀的平台，VISUAL C++在目前来讲，功能要比DELPHI强大，主要是因为DELPHI5.0的原装文件中，缺乏大量的VISUAL C++原本应该包括的大量的头文件，使得大量底层WINDOWS资源不能访问（例如DELPHI中的MAPI.PAS就缺乏关于MAPIX方面的说明，使得有关MAPIX的程序如ExchangeServer高级编程不能使用DELPHI,除非你在网上下载到相关的.PAS文件），但是，我听说，在网站上已有很多第三方提供了这些能实现底层资源访问控制的适合于DELPHI用的.PAS文件，如果真能下载装配完这些文件，我想DEIPHI的功能将大大加强。另外，DELPHI在多线程编程时，其同步的类型使用较少(主要是Windows核心对象如关键体，互斥体，信号灯等未在VCL库中封装成TMUTE等类，而是统一用一个自己的同步函数），程式编制不灵活，其用户界面线程功能较弱，但是，DELPHI提供了大量比VISUAL C++多得多的可用的现成资源，特别是在数据库编程方面，VISUAL C++是万万比不上的。在代码封装重用方面，DELPHI提供的开放式组件功能也比VISUAL C++强得多，且DELPHI入门简单，易学，在一般应用的开发速度远远高于VISUAL C++，另外，DELPHI的VCL库直接与COM为基础，这是未来软件设计的趋势，比Visual C++的MFC的层次要高。然而DELPHI程序员编程水平提高较难，只因VCL的封装较为高档，离WINDOWS底层较远，在某些SDK编程方面DELPHI因缺乏可用的.PAS文件而不能深入编程。VISUAL C++是目前功能最强大的开发平台，其在WINDOWS上几乎可以作任何工作，然而VISUAL C++入门极其困难，它的入门与其说是在学一种语言，不如说是在了解WINDOWS工作的核心，不了解WINDOWS的工作核心，根本谈不上用VISUAL C++的编程。从工程的角度上来讲，因MFC的封装远远比不上DELPHI的VCL库，所以VISUAL C++是一种吃力不讨好的工具，开发工作量繁重；从编程技巧上来讲，VISUAL C++到确实是一种万能的工具。当然，如你有充分的时间和精力的话，也可以用VISUAL C++写出大型的精良的系统。从应用软件的体积上来看，VISUAL C++的应用程序确实要比DELPHI同样的应用程序小很多，DELPHI应用程序的“臃肿”名不虚传。其实，这两中平台中间有一个折中平台，那就C++ Builder,它不仅拥有VISUAL C++的全部头文件，还有DELPHI的全部资源文件，整个平台程序开发迅速，也有能力完全访问WINDOWS核心，与各类SDK接口完整，程序质量可高可底。然而，C++ Builder也有其缺陷，第一个同样是和DELPHI同样存在的线程问题；第二个是C++ Builder编译速度奇慢，对开发员使用的机器要求很高（建议开发机CPU至少应为P3以上，内存128M以上）抬高了开发成本；其实，对于程序开发员来讲，仅考虑使用一种开发平台显然是不够的，对于有基础的程序员来说，只要你对WINDOWS核心有一定了解的话，使用何种开发平台、何种语言并不非常重要，因为开发平台和开发语言只是一种基础工具，关键是开发工程的实质是什么，开发成本有多少，开发时间有多长，不必要局限于某一种特定的开发平台和语言。我个人推荐，平常的应用用C++Builder,难度攻关用Visual C++,攻关成功后，可将代码转换给C++Builder使用。当然DELPHI也不能放弃，深入DELPHI的VCL源代码有助于将你的C++Builder应用的用户界面等涉及到开发平台本身的一些技巧得到提高。此仅为个人观点，望各位大虾指正。我认为讨论一下VISUAL C++和DELPHI是很有必要的，两种平台同样是世界上最优秀的平台，VISUAL C++在目前来讲，功能要比DELPHI强大，主要是因为DELPHI5.0的原装文件中，缺乏大量的VISUAL C++原本应该包括的大量的头文件，使得大量底层WINDOWS资源不能访问（例如DELPHI中的MAPI.PAS就缺乏关于MAPIX方面的说明，使得有关MAPIX的程序如ExchangeServer高级编程不能使用DELPHI,除非你在网上下载到相关的.PAS文件），但是，我听说，在网站上已有很多第三方提供了这些能实现底层资源访问控制的适合于DELPHI用的.PAS文件，如果真能下载装配完这些文件，我想DEIPHI的功能将大大加强。另外，DELPHI在多线程编程时，其同步的类型使用较少(主要是Windows核心对象如关键体，互斥体，信号灯等未在VCL库中封装成TMUTE等类，而是统一用一个自己的同步函数），程式编制不灵活，其用户界面线程功能较弱，但是，DELPHI提供了大量比VISUAL C++多得多的可用的现成资源，特别是在数据库编程方面，VISUAL C++是万万比不上的。在代码封装重用方面，DELPHI提供的开放式组件功能也比VISUAL C++强得多，且DELPHI入门简单，易学，在一般应用的开发速度远远高于VISUAL C++，另外，DELPHI的VCL库直接与COM为基础，这是未来软件设计的趋势，比Visual C++的MFC的层次要高。然而DELPHI程序员编程水平提高较难，只因VCL的封装较为高档，离WINDOWS底层较远，在某些SDK编程方面DELPHI因缺乏可用的.PAS文件而不能深入编程。VISUAL C++是目前功能最强大的开发平台，其在WINDOWS上几乎可以作任何工作，然而VISUAL C++入门极其困难，它的入门与其说是在学一种语言，不如说是在了解WINDOWS工作的核心，不了解WINDOWS的工作核心，根本谈不上用VISUAL C++的编程。从工程的角度上来讲，因MFC的封装远远比不上DELPHI的VCL库，所以VISUAL C++是一种吃力不讨好的工具，开发工作量繁重；从编程技巧上来讲，VISUAL C++到确实是一种万能的工具。当然，如你有充分的时间和精力的话，也可以用VISUAL C++写出大型的精良的系统。从应用软件的体积上来看，VISUAL C++的应用程序确实要比DELPHI同样的应用程序小很多，DELPHI应用程序的“臃肿”名不虚传。其实，这两中平台中间有一个折中平台，那就C++ Builder,它不仅拥有VISUAL C++的全部头文件，还有DELPHI的全部资源文件，整个平台程序开发迅速，也有能力完全访问WINDOWS核心，与各类SDK接口完整，程序质量可高可底。然而，C++ Builder也有其缺陷，第一个同样是和DELPHI同样存在的线程问题；第二个是C++ Builder编译速度奇慢，对开发员使用的机器要求很高（建议开发机CPU至少应为P3以上，内存128M以上）抬高了开发成本；其实，对于程序开发员来讲，仅考虑使用一种开发平台显然是不够的，对于有基础的程序员来说，只要你对WINDOWS核心有一定了解的话，使用何种开发平台、何种语言并不非常重要，因为开发平台和开发语言只是一种基础工具，关键是开发工程的实质是什么，开发成本有多少，开发时间有多长，不必要局限于某一种特定的开发平台和语言。我个人推荐，平常的应用用C++Builder,难度攻关用Visual C++,攻关成功后，可将代码转换给C++Builder使用。当然DELPHI也不能放弃，深入DELPHI的VCL源代码有助于将你的C++Builder应用的用户界面等涉及到开发平台本身的一些技巧得到提高。此仅为个人观点，望各位大虾指正。

[Jujus]

讲的好！！！！！

[kinghan]

你真是费心了！
其实Visual C++不是很难学，使用起来也还算方便。