用Delphi一样能做的非常好,就看你的水平
解决方案 »
- 开帖散分,9/10[铁公鸡拨毛]
- 求救求救,帮我参谋参谋吧
- 程序员,你的性格决定了你的命运!
- 请问,可否用DELPHI打开一个没有工具栏和菜单栏的IE浏览器?怎样实现?
- 关于相对路径
- 高分求解:在客户机上运行客户端程序,怎样编写一个按纽,把选择出来的显示在dbgrid 中的数据导出到access中去,并保存,!请详细点!在
- SQL Server中能否建立字段级触发器?(详细内容入内)
- 哪儿有好,新,多,全控件下载
- 有没有搞错,自定义函数过程里不能使用控件的属性?
- 如何给Word2000增加自己的菜单?送80分!
- 靠,一群笨蛋,那个能解决我的问题?TMainMenu有办法放到TCoolBar里面去么?非得用coolbar+toolbar+flatbutton去做可以dock的菜单么?
- 菜鸟问题!!帮助者给分
Delphi开发组件速度比ATL快。
别人怎么说,让别人说去,关键是你自己怎么看最重要。
我曾听李匡正(Borland TaiWan)说过,Delphi在3.0后,COM作的比微软还出色。我虽然不是非常熟悉VC,但是我觉得为什么微软不用MFC,而却开发了一个ATL来写COM。而且,我觉得ATL并不比Delphi的interface方便,要自己弄那个IDL。
另外说一句,你用过Delphi的COM编程吗?
不会吧,应该反过来才对,在大型系统中,delphi用的远远比vc广泛(com,com+,dcom,corba)。据我所知国内,目前国内大部分证券行业的三层应用都是基于dephi,或bcb,的。证券行业也是目前windows平台技术作的最好的,他(证券)也是最早的三层应用的倡导者,实践者,无论从系统的大小,复杂程度都是其他行业所南比拟的,(金融,电信系统一般都是基于unix平台),我觉得用vc才是值得怀疑的?
举双手同意airhorse(编程至尊宝)
一般的看来,vc是ms出的,和windows操作系统有天然的亲和力,在我用delphi写一些系统方面的应用不能成功时,我转而求助于vc---在我重新花费了一两个月拣起vc后,自然的和我更熟悉的delphi比较了一下。
我所做的东西需要一个dll,全部用c(完全的api)写,在vc中编译,生成的文件的大小有132k,优化之后还是有67k!。在delphi中,我用api写,编译再优化之后,大小只有18k!(说实话,我不知道ms费尽心思在系统中装那么多的mfc??.dll之类的是干什么用的。)
再说写一个exe引用这个dll,同样的移植,在delphi中的异常保护比vc更好,我的程序在delphi还能运行,在vc中能编译成功,但是一运行就crash!
dephi 高级编程,也不是一段时间就可以学会的,dephi除了界面及控件还有很多东东,1,直接兼容 ms socket(不是控件),api
2,高级线程机制(提供多种完备信号量及同步机制)
3.利用windows消息机制,封装消息,可以简单方便的写一个自己的消息,不再是一个烦琐的东东 .......
一个计算公式循环上万遍,发现delphi比vc快。这是有可能的。但是我们知道,评价一个东西是否比另一个快,不仅仅是某一个独立的方面:比如数据库吧,Foxbase插入一万行记录绝对比某些大型SQL数据库来得快。:) , 需要综合比较,我一口咬定delphi比c++慢,是因为我看到的是
Borland公司的资料,他们说比VC只慢20%,我想这可信度比较高一些吧。另外,关于: airhorse(编程至尊宝) 的那几点Delphi的高级编程,已经不是Delphi本身的东西了,是调用 API , 关于这,如果VC学得好,对用Delphi来作是很有帮助的,BigBen(江南草)应该有和我相同的经验。我觉得delphi的高级编程应该在其三层构架上吧。再有,BigBen(江南草)遇到的情况,同样程序VC 67K , Delphi 18K , 完全是正常的。因为对一个小程序来说,C++连接了太多不必要的模块(但对C++来说是必要的,如果用了MFC,那就更庞大了,呵呵) , 但是如果程序规模很大了,情况就会反过来。