13,824
社区成员
发帖
与我相关
我的任务
分享Visual C++ vs C++ Builder
我想这篇贴子再这儿发表回引来很多不同意见，然而这正是我所想看到的。（这篇贴子我曾在商都BBS上贴过）
VC vs CB
1、从编译器角度看，CB强与VC。在编译小的程序时，CB的优势尤为明显。例如：用API写一段只显示一个窗口的win32程序时，CB编译的只有40多k，而VC却要80多k。但是，如果是用CB&VCL编程，情况就不同了，由于VCL时用OOPascal写的，编译时需链入额外的库，造成的结果是同样的程序，CB竟然比Delphi还大。是否比用VC&MFC写的程序大，我没有比较过，但我想这是肯定的。编译速度我没有定量比较过，感觉两者差不多，都比Delphi慢多了。
2、从编辑器角度看，VC强与CB。我想大家都会有同感。VC编辑器的智能化很好，当输入一个类名後，他会立刻以列表框方式显示所有定义的成员。CB（包括Delphi）也有同样功能，但反应速度太慢，等他反应过来，我已经输入8遍了。
3、MFC与OWL的优劣之分，是软件专家的事。本人才疏学浅，不敢妄议。但我认为把VCL放在一起和他们比较，是不妥的，因为他们根本是两码事。如果按标准叫法，前者是框架，后者叫构件。构件是以属性、方法、事件和程序员交互的，框架没有这些概念。构件确实给开发效率带来了好处，他也许是未来Visual Programming的发展趋势。Microsoft不是没有能力在VC中引入构件（VB的ocx不都是用VC写的吗），之所以Vc不采用他，我想大概是考虑到构件的使用会降低VC程序的执行效率。
OWL优于MFC，这种说法我不止一次见过。似乎已成定论。权且认为它是真理吧。然而OWL红颜薄命，由于市场的不成功，Borland也懒的给他升级。从Borland C++5 之后，这么多年了，未见OWL的新版问世。Borland却要向Microsoft购买MFC的许可权。但是，奸诈的Microsoft会把MFC的最新版的许可卖给Borland吗？不可能。
其实，OWL优于MFC之说，我也有点保留意见。MFC对API的封装很薄，薄到让你看见API的影子。这让熟悉API（SDK）编程的人看起来感到很亲切，乐于接受。而先学API编程，再学框架编程是成为Windows programmer的康庄大道。我没听说过哪个成功的Windows programmer不是这样走过来的。直接接受框架编程，会让你越学越糊涂。我有切身体会：本人曾借到一本书，好像是“24学时精通MFC"，结果24天过去了，连第一章也没看懂。同时，MFC又比OWL好学（听说的，我不会OWL）。在这种情况下，读完了Petzold的Programming Windows，理所当然的该读MFC的书了，谁去学OWL呢？
4、从学习资源的角度看，CB远不如VC。CB的用户量比VC少的多，是你很难找到志同道合的朋友一起切磋;CB的参考书少（我指高水平的书，不是国人写的入门书），你不得不去买Delphi的书去学CB；CB的网上资源也少，（注：inprise的社区是最好的学CB的地方）。
5、最后一点、也是最重要的一点。记住：Windows是Microsoft的OS，VC是Microsoft为Windows设计的开发工具。最新的Windows技术，总是在MFC中得到实现。我认为，一个以Windows programming为职业的人（而不是作为业余爱好的人），应选VC为开发工具。个人认为如果不是对C++太热衷的话，选CB还不如选Delphi。也许CB会成为Linux下的最佳选择，但它还没有问世。
本人入道不久，见识尚浅，有写的不对之处，望各位网友指出。
注：对指出我的贴子中的错误的朋友，我将给分。
VC vs CB
1、从编译器角度看，CB强与VC。在编译小的程序时，CB的优势尤为明显。例如：用API写一段只显示一个窗口的win32程序时，CB编译的只有40多k，而VC却要80多k。但是，如果是用CB&VCL编程，情况就不同了，由于VCL时用OOPascal写的，编译时需链入额外的库，造成的结果是同样的程序，CB竟然比Delphi还大。是否比用VC&MFC写的程序大，我没有比较过，但我想这是肯定的。编译速度我没有定量比较过，感觉两者差不多，都比Delphi慢多了。
2、从编辑器角度看，VC强与CB。我想大家都会有同感。VC编辑器的智能化很好，当输入一个类名後，他会立刻以列表框方式显示所有定义的成员。CB（包括Delphi）也有同样功能，但反应速度太慢，等他反应过来，我已经输入8遍了。
3、MFC与OWL的优劣之分，是软件专家的事。本人才疏学浅，不敢妄议。但我认为把VCL放在一起和他们比较，是不妥的，因为他们根本是两码事。如果按标准叫法，前者是框架，后者叫构件。构件是以属性、方法、事件和程序员交互的，框架没有这些概念。构件确实给开发效率带来了好处，他也许是未来Visual Programming的发展趋势。Microsoft不是没有能力在VC中引入构件（VB的ocx不都是用VC写的吗），之所以Vc不采用他，我想大概是考虑到构件的使用会降低VC程序的执行效率。
OWL优于MFC，这种说法我不止一次见过。似乎已成定论。权且认为它是真理吧。然而OWL红颜薄命，由于市场的不成功，Borland也懒的给他升级。从Borland C++5 之后，这么多年了，未见OWL的新版问世。Borland却要向Microsoft购买MFC的许可权。但是，奸诈的Microsoft会把MFC的最新版的许可卖给Borland吗？不可能。
其实，OWL优于MFC之说，我也有点保留意见。MFC对API的封装很薄，薄到让你看见API的影子。这让熟悉API（SDK）编程的人看起来感到很亲切，乐于接受。而先学API编程，再学框架编程是成为Windows programmer的康庄大道。我没听说过哪个成功的Windows programmer不是这样走过来的。直接接受框架编程，会让你越学越糊涂。我有切身体会：本人曾借到一本书，好像是“24学时精通MFC"，结果24天过去了，连第一章也没看懂。同时，MFC又比OWL好学（听说的，我不会OWL）。在这种情况下，读完了Petzold的Programming Windows，理所当然的该读MFC的书了，谁去学OWL呢？
4、从学习资源的角度看，CB远不如VC。CB的用户量比VC少的多，是你很难找到志同道合的朋友一起切磋;CB的参考书少（我指高水平的书，不是国人写的入门书），你不得不去买Delphi的书去学CB；CB的网上资源也少，（注：inprise的社区是最好的学CB的地方）。
5、最后一点、也是最重要的一点。记住：Windows是Microsoft的OS，VC是Microsoft为Windows设计的开发工具。最新的Windows技术，总是在MFC中得到实现。我认为，一个以Windows programming为职业的人（而不是作为业余爱好的人），应选VC为开发工具。个人认为如果不是对C++太热衷的话，选CB还不如选Delphi。也许CB会成为Linux下的最佳选择，但它还没有问世。
本人入道不久，见识尚浅，有写的不对之处，望各位网友指出。
注：对指出我的贴子中的错误的朋友，我将给分。
...全文
请发表友善的回复…
发表回复
xubin_sh 2000-08-09
- 打赏
- 举报
cb编译出来有多大我不知道，但是vc6编译出来是 28,672byte 你可以试一下
tonyyang 2000-07-21
- 打赏
- 举报
我认为Winsun 说的很有道理。从TC,BC++,VC++,Delphi,BCB没有永久的常胜将军，也没有完美无缺的工具。要根据Case的要求选工具。
xqiqi 2000-07-20
- 打赏
- 举报
我觉得影响我们选择工具的因素里非技术因素很重要，比如我用VC就基于这样一些原因。VC软件是最容易得到的，VC的资料是最多的，VC是微软公司的产品，还有一点我个人认为很重要，就是微软不会倒，即使被分解。至于编译器效率、类库是否优秀，对我来说没有关系。
jiujiejushi 2000-07-19
- 打赏
- 举报
我觉得影响我们选择工具的因素里非技术因素很重要，比如我用VC就基于这样一些原因。VC软件是最容易得到的，VC的资料是最多的，VC是微软公司的产品，还有一点我个人认为很重要，就是微软不会倒，即使被分解。至于编译器效率、类库是否优秀，对我来说没有关系。
Wingsun 2000-07-19
- 打赏
- 举报
我认为在现在的条件下，程序的大小和速度不是一个程序的主要方面，重要的是功能。我们是一群靠编写程序为生的人，我们的目的是写程序，通过写程序来获得保证自己生存的所必需的物质条件。我们需要的是能够快速高效低编写的程序的东西，我们不是艺术家。BCB与VC的比较我只能从我的角度来考虑，根据我的需求和上司、客户的要求来选择使用什么样的工具。对于比较简单和要求迫切的工作我会使用BCB，对于要求较高，难度较大的我会考虑使用VC，但是他们绝对不是我的一个工程/项目中的唯一开发工具，我可能用到Delphi、VC、VB、BCB等等工具，对于我来说他们仅仅只是工具而已。工具嘛只要能实现你要的功能就行了，不必去看一看他究竟是姓什么的，Microsoft,Borland or sybase等。也没必要费那么大的劲去考察他们。
