越来越觉得delphi烂！(0分)

上面那个问题，我也遇到过。刚开始时，我也觉得莫名其妙，以为是我程序哪儿出了问题，
后来仔细检查，才发现如此。

假设从办公室到家有2000米，
有三种方式来选择，走路，跑步，骑自行车，
怎么选择呢？

mark_du 告诉我们吧！

LiChaoHui:
我来告诉你吧.
1 办公室到家, 我会坐车. (早回家嘛.[])
2 家到办公室, 我会走路,( 不想上班嘛.[])
3 钱包丢在办公室了, 我会跑步.[!]

不是开玩笑. 我觉得mark_du说的对, 具体情况具体分析,没有固定的模式可用.

我觉的开发工具都不错呀,因为写他的人水平不知比我高多少倍,简直没有可比性,工作中选用开发工具完
全取决于管理者和具体的项目,没什么争的,叫你用你能不用除非你不以编程做为职业!

争来争去全是废话:我们用的计算机软硬皆是洋人的,你能说BIOS就写的很好吗?不一定,因为我们没机会深入它所以就理所当然的不去理会它!

如果是发烧友,选定一个工具把它用到极致就够了.

to yeskert1:
在Delphi中怎么用原生ADO阿？ 我是新手，
在这里回答或是wqthai@163.com
我先谢谢你！！我在Delphi中，打了ADO的补丁，升级了Delphi5,
在使用ADO组件时还是会出现类似“不是文件底。。。”等报错。

to BKBK3000，
现实情况往往比较复杂，处理一种问题可能有多种方法，
哪一种方法更好，大家或许会有不同的结论，并且都以为自己的对

to BKBK3000
Delphi不阻碍你用SDK呀。愿意用Delphi通过SDK写一个ERP你也可以去写。
累死你

楼主好象从来没写过C++程序
一个没有基础类库的东西你也能用？？？难以理解。
如果说VC不用MFC，那就是说VC没有了基础。使用一个没有基础的东西，
真是服了你了！
不要说SDK是VC的基础，如果这么说，那只能说你根本没写过程序。

看到大家争论了很多。我觉得还是瞒有意思的。
现在很多人使用一种东西就把他吹到天上去了。比如使用unix的人，看不起windows的东西，而且是盲目的排斥。
于是，我开始学习unix和linux，现在我对linux和unix系统非常熟悉了。才发现，其实windows有很多地方是
非常先进和值得学习的。并不是他们说的一无是处。而unix和liunx也不是什么都好。
我是用basic，然后用tp5,一段时间用tc2。对borland，在dos时代，几乎是我唯一的选择。但是到了bc++时代，
我放弃了，转向了vb，后来一直用vc＋＋。其他工具比如pb也用过。
使用delphi的人，很多盲目的排斥ms的产品。不过，我到觉得vb，vc++不是很多人说的那么差。
相反delphi也不是很多人说的那么好。
设计程序，其实什么快，什么好。比如我曾写过一个网络电话的程序。一切，必须要自己重头坐起。
我觉得vc++真的非常适合这个程序。现在我在写一个mis系统。我选择了delphi。其实，我觉得用vb其实挺好，
不过，为了多学一个东西。到目前，使用delphi写了2个mis系统了，现在这个还没完工。发觉，delphi方便还是
方便。但是他的控见有时候真的不敢恭维。很多人说，你不懂delphi，这点我承认，我一直就是把他当成一个
mis系统的RAD。所以，我根本不会去看他的什么vcl代码，我只是用用而已。
使用pascal作系统编程，我不知道大家是什么感觉。我总是觉得很奇怪。个人觉得c和pascal的风格差异瞒大的。
在使用c的系统的平台上，调用c格式的api，使用的是pascal。我非常难受。觉得完全是多此一举。无论在windows平台
还是unix平台，使用c/c++就行了。多方便。这就是c/c++比pascal好的重要因素。也许大家不同意，但是，我们在这个系统上
编程，我们没有选择。使用c/c++无疑是最方便和快捷的。
我现在两个都用。vc++，vb用，delphi，bcb也用。什么快用什么。对delphi没有必要学的那么深入。如果你要深入，直接使用
c/c++,作系统sdk编程就完了。你明白了系统的原理，这个工具在你眼里无非就是不同包装的不同参品而已。
最后奉劝后来者，delphi不错，但是千万不要一颗树上吊死。使用c/c++，研究系统原理。才是程序设计的本质。
为什么了，因为我们是在c/c++编写的操作系统上写程序，不低头不行。

争论语言优劣很无聊
不过说句实话，学好C++走遍天下，PASCAL却只能（或者说适合）在WINDOWS应用程序开发上施展
楼主还是把DELPHI学好再这么说

"用用而已"的人是没有资格评论的。
你这个“烂仔”（cyhan说的），哈哈

和一个不懂Delphi，不懂ADO的人谈论这些，是对牛弹琴
也不会把TAOTable的CursorLocation改称clUseServer试试，笨蛋一个
还有CursorType，如果你的数据库支持ctDynamic类型，就改成ctDynamic

只是用用而已，就拿来做商业程序，程序的质量可想而知...

在使用c的系统的平台上，调用c格式的api，使用的是pascal。我非常难受。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
对了，其实是C调用Pascal的API,难道你不知道所有Window API函数的
声明都有WINAPI,你不会不知道这是什么意思吧,不,你肯定不知道,要不
你不会说出那样让人耻笑的话,果然是笨蛋.

我们说了那么多这种东西的好处，我来说几样我不满意的地方，
当然这些不满意都是通过对比产生的，决不像某些人所说的没有可比性，

我用VC的时候，对象之间的耦合很费了我一番心思，对于坚持面向对象思想的我，
我不愿意用全局变量来进行对象之间的耦合，但我想不出更好的办法，
他所谓的经典文档视图结构对我全无意义，最终我按照自己的想法设计了窗口结构，
当然，这些事情在Delphi中会是一件非常简单的事情，也许，是因为我违背了MFC的初衷
也许，是我对MFC太过于陌生，但是公司中有的是比我资深的前辈，他们也没有解决好这些事情
窗口的结构他们基本上遵循与MFC的结构，但是设计复杂的界面实在是一件痛苦的事情，
她们上网查资料，寻找例子程序，最后模仿而成，然而，
对Delphi来说这是多么简单的一件事情啊，甚至不用写一行代码，

最终，我选择了利用消息或者CmdMsg虚函数来实现对象的耦合，
我发现这一点是多么的不容易啊，这些灵感都是来自于Delphi的虚函数，
我多么怀念Delphi中的事件啊，虽然现在的新的开发工具都对事件有了充足的支持，
但在VC中，感觉一切都是那么别扭，我想，一方面是因为我先入为主的学习了Delphi
另一方面，MFC已经有了十多年的历史了，在它诞生的时候也许他很先进，可是现在
它老了!......

后面的一件事情，也使我很不愉快，我的监视界面需要动态的显示程序运行的状态图，
需要用直线图来显示，我知道有Activex控件能够胜任，但是，一来我对调用Activex控件
没有经验，我也不想我的程序发布的时候还要带上一个附加的ocx文件
（可能是因为用多了Delphi的缘故），最后我决定自己来画这个图表，
于是，我同各种dc打交道，和一堆的刷子和画笔打交道，代码写的可是真不少，
我都熟悉了和这些东西相关的大部分API函数了，我也明白了MFC是API的简单封装所包含的意思了
代码量很大不说，我还要小心翼翼的防止资源的泄漏，还要恢复刷子和各种GDI对象
同时，我也学习了脱屏位图双缓冲的技术，当然这是参照了VCL中的部分源码写出来的
因为我找不到更好的参考资料了，作这各个东西花费了很长时间，对于学习GDI的API
可真是功不可没，但我最终明白了，学习这些东西用处不大，因为我以后很少再这样写程序了
这使得我更加怀念Delphi 中的Canvas用起来是多么的方便啊，完全不必担心资源泄露的问题
如果用TChart来做，也许是几个小时甚至几十分钟的事情，然而我用VC却做了一天多的时间

做出来的效果，另那些VC高手都赞叹不已，然而，我知道，如果用Delphi，我可以做的更漂亮些

这就是我对VC的感受，这不是因为我不了解它，恰恰是因为我了解了他

只有不懂编程的人才一时抱怨这个,一时抱怨哪个.
说delphi不能搞底层没vc好啊,又说什么vc控件太少等等
又说c#出来了 c++没搞头了

真正的高手是不会计较这个的
我觉得如果你能象 安德尔森那样用汇编写个 tc
你还有点资格说

softman11:
争论到现在，其实已经有人给出了两种解决方案：
1。换个ado控件，不用delphi 自带的，比如Adonis Component Suite 4.3
或Diamond ADO 1.8，这就是我认为的delphi的一大好处，你有很多选择，borland自带的
控件不好，你可以选择其他第三方控件，但高手好像都不屑为之。
2。TAOTable的CursorLocation改称clUseServer
建议你先试试，看能不能解决，当然如果你改用vb或vc就算了。
另外我估计您是个高手，为什么呢，高手都很自负，东西不顺手，还是照用，而且绝对不用
第三方控件，因为自己都能搞定。
我怎么知道呢，因为你作报表用quickreport，那是个垃圾，我这种懒人是绝对
不用的，但我发现新手和高手都特别喜欢用。

我不喜欢乱说话的，胡乱说出来的话缺乏说服力，
也许我是有偏见的，我拿一个东西的长处来和一个东西的短处想比较，
但VC的长处是什么呢，我知道，大家都会说诸如：底层开发啦，
贴近操作系统啦，运行效率高了.....
可是，他们了解Delphi吗，在这些方面Delphi一点都不差，而且编译速度是世界上最快的
那些坚持VC++的人，无非是他们在学习VC的过程中付出了太多的艰辛和努力，
取得的一点成绩都很不容易，他们觉得还没有学到家，不能半途而废...

我所见到大多数坚持学习VC的人，莫不是盲目排外，对Delphi 不屑一顾，
认为学好了VC就牛了，什么都不怕了，
懒惰是人的天性，不喜欢学习也无可厚非，也需要找些借口来推搪一下嘛

下面再说一点我对VC的不满，这是个人的一点体验，充满主观观念，欢迎大家批驳
我说到，我最后决定使用消息来进行对象的耦合，那么就需要进行自定义消息，
和消息映射，查了半天的MSDN,终于知道怎么做了，可是后来又需要进行消息映射，
又不会了，没办法，复制粘贴搞定，虽然我做过很多次，可是我现在仍然不会，
记性差是程序员的通病，VC难学就难在这个地方，有人说在同一个摔一次跤，记住了
是聪明人，如果两次才记住，算是个普通人，如果三次才记住，那就是个笨蛋
我在VC面前是一个彻底的笨蛋，我的信心经受折磨，而且还有怀念以前美好时光的痛苦
我知道在Delphi中进行消息映射是多么简单的一件事情啊，与VC的复杂繁琐简直不能相比

此时，我已经明白，MFC也许早已经完成了它的历史使命，我不愿意再深入的学习VC++了
因为我有更好的选择，Delphi，C#，。。。。
现在，MFC已经显得落后了，显得不方便，显得繁琐，它的所谓标准经典框架，
也是对程序员的极大束缚，

故事继续中...........

后来，由于工作的关系，我又不得不使用VC来写程序，
我想模仿我曾经实现的那个框架，来建立程序框架，
可是，我写不出来，MSDN已经被我卸载了，
在第一次写程序的时候，MSDN成了我最好的朋友，我从来没有像那时那样那么需要它，
虽然MSDN中检索信息的速度非常得快，但是还是占据了我很多的时间，
我花了太多的时间来查阅MSDN,
然而，我再一次写一个类似的程序的时候，却要从头再来，
这是多么痛苦的一件事情啊，毫无疑问，这痛苦来源于Delphi
如果我从来没有接触过Delphi ，从来不精通Delphi我就不会有这样的烦恼了
正是，经历了快乐，才知道什么叫痛苦，经历了痛苦才知道什么叫快乐，
曾历富贵，又怎能忍受贫苦的生活，这都是对比的结果，俗话说，人比人，气死人
最后，没有办法，在我心中不停的怨骂中，重写了那个框架，写完之后，
反而觉得VC也不是很麻烦，甚至还有一种成就感，差点就爱上它了，
艰难繁琐之后的成就感，让人觉得精通VC的确是让人引以自豪的东西，
而Delphi确是没有这种好处的，它只会让人觉得，太简单了，不值得自豪，
甚至觉得，一个高中生都会，有什么了不起的。

Delphi让我又爱又很，不过是爱大于恨，VC++然我又恨有爱，却是恨大于爱，
前者是很铁不成刚，后者是因为它能充分满足我的成就感，
但MFC的确太落后了，也许不久就会被抛入历史的垃圾桶，当然我也不否认，
一些无知的后辈会将它奉若至宝，

我想说，别了VC,而Delphi至少现在是我的首选，
将来说不定了，总之我选择工具的标准是，简单，易用，方便，快捷，
我不在乎是出自于microsoft还是borland,甚至是中国的某个软件公司

故事继续中.......

我想说的是，用VC的时候需要程序员有极大的耐心，有很好的记忆力，
（可记忆力差是程序员的通病），有足够多的文档资料可查，

对于Delphi完全不需要，通常根据属性或方法的名字就能猜到他的用途，
而且学会了使用一个控件就像学习骑自行车那样很难忘记，Delphi比较适合懒惰的
记性较差的程序员

于是，我对 真正的程序员用C/C++ 聪明的程序员用 Delphi 有了更深一层的理解
当然，其中的C/C++特指VC

C++Builder基于VCL类库，是个很好的C++,但是觉得没有Delphi方便，便没有深入的学习
不过学习C++Builder的同事倒是经常来向我请教问题，也都能得到满意的答复，
因为都是用的VCL类库嘛

下面是一句代码在Delphi和C++Builder中的区别
C++Builder:
Caption = ListBox1->Items->Strings[0];
Delphi:
Caption := ListBox1.Items[0];

所以，我更喜欢Delphi