哪位牛人能跟我讲讲DELPHI语言的不足之处,越全越好!谢谢!

现在说点实在的~~delphi最大的不足就是把ide做得太强大了vcl大猛了
害得很多学习的人都越来越懒了，不用控件他们会做的事情就不多了

那确实.先声明,我不牛人.Doing Delphi你们觉得Delphi象不象娥眉派的剑宗,招式出神入画/
C++就有点象气宗,学起来慢.

我现在发现的,也是最希望得到解决的就是,Delphi内存管理在多线程下的瓶颈.

    * unsigned
    * 僵哥
    * 等　级：
发表于：2007-08-16 19:36:53 7楼得分:0
我现在发现的,也是最希望得到解决的就是,Delphi内存管理在多线程下的瓶颈.--------------------这个解决起来太难了点，不过也有方法的$80000000-$ffffffff这些空间delphi没办法直接访问，确实有点郁闷
可以考虑用creatmapfile申请位于80000000以上的空间，不过与它通信就好难了

to brightyang
那段空间地址用不用到没有太大关键,通常程序不需要那么多的内存,否的话,需要通过OS设置使用2G以上的内存,如果还不够可以使用APE使用更多的内存.
这些其实都不是问题,关键就在于Delphi特别是内置的String呀类呀什么的,大家共用一个内存管理器,而使用Delphi,大家最最用得频繁的就是String,而这个时候频繁地内存申请和释放就会由于单一内存管理器当中各线程互锁而导致形成瓶颈.目前想倒是想到了一个针对高并发的网络服务端的处理方案,不过感觉上不管是采用什么方式处理,总会有相当的问题存在,在不对原内存管理器进行优化的情况下,资源的利用总难达到最优化.方案1.采用多进程服务并行服务
即,为各CPU(以目前的多核技术,只须考虑CPU数量就足够了)创建独立的进程并且指定只能在相关的CPU上执行,如果达到单一内存管理器锁定在单一CPU上,减少因为线程发并而导致的不必要的互锁.从理论上来讲,确实可以更好地利用并发线程隔离机制来达到性能提升.但是各进程任务的适配就成为了一个问题,这个均衡器的设计有相当的难度.只能针对性地处理,比如说,高并发的网络服务程序,在Winsock2当中允许地址重用,即同一个端口允许多次绑定和监听,这种机制在Unix/Linux下各进程的优先级是相等的,即任何一个进程都有可能收到网络报文,而Windows当中是按进程的绑定顺序来的,任何一个进程只要在之前绑定过一次,那么任何时间在进程不退出的情况下,关闭掉监听之后会转让给下一个监听进程去处理网络事件,但是当这个进程再次监听,包括重新创建Socket并绑定,仍然具有更高的优先权,按照这个规则,即可将同一个程序运行多个副本,然后同时监听同一个端口,接受新的连接,对于AcceptEx得到的Socket在关闭了Listen Socket之后仍然是有效并可以服务的,当用户数量达到一定的时候,即可将Listen关闭,而让新来的连接切换到下一个进程当中,当前面的进程允许接受新连接的时候,可以再启动监听,而抢夺取新连接的客户．如此一来对于高并发连接的情况下在一定程序上可以更好的利用服务器的资源．方案2.使用ＴＬＳ(Thread-Local Storage)，做内存池，避开线程之间的竞争，达到高效率．（这个需要良好的线程管理设计体系，否则很容易造成内存的过度非必要性地占用）方案3.全局多内存池管理．采用单一内存管理器，进行内存的多池管理机制，采用尝试访问替代竞争来达到内存管理．方案4.使用方案3类似的方式，修改Delphi的内存管理器

c++与object pascal都不错,我都很喜欢

Delphi唯一的缺点就是语法不能玩深层,写不出让人看不懂却能正常运行的代码.

缺点1:
  提供太方便的RAD开发环境.很多人只会拖拉控件不求深入.给人会Delphi的人都很浅显的印象.
缺点2:
  功能太强大,我以前写驱动程序的时候一定还要用Delphi做一个.无论底层,上层,网络什么都面面俱到.会Delphi给人不专的感觉.缺点3:
  Borland不会宣传.C#出了个Attrib(属性)概念.就吹得要死.说是他的首创.Java好不容易可以把设计期东西保存到XML里面就大吹大擂.仿佛是多了不起的创新.Delphi的dfm文件早就问世N多年了.
  反正Delphi的概念很领先.就是Borland不会造势.别人学来了都可以宣传的有声有色.

有没人实现Delphi类似C#反射机制？

我晕.反射机制也是Delphi先发明的啊.只是C#学来以后使他变得更完整了一点而已.
差别也没啥

再补充一点.反射是建立在RTTI基础之上的.Delphi和C#的反射基本差不多.
最重要的差别就是Delphi只有Published成员才具有RTTI信息.
而C#所有的成员都具有RTTI信息.
Delphi的IDE和设计时都是利用所谓的"反射".
Delphi可以知道成员所在模块,单元,属性信息,事件信息,方法信息等.

记得当年微软内部有个人的笔名叫做Buck Forland, 估计就是楼主了，呵呵

我只知道这东西能用，有什么想法基本都能实现。语法慢慢地适应了C再好但没有一个这么好的IDE,自己还可以做第三方控件。PS:好像没有delphi这个语言，delphi是一个总称。

Object Pascal还是很不错的
只是工具限制了应用领域而已
不是语言自己的问题

楼上有位达人说了,Delphi做的事情太多,导致用Delphi来开发,可以做的事情已经没有多少了,因此用了很久的Delphi以后,还是一个程序设计"工具"使用者,而不是一个程序员,因此,建议初学者不要用Delphi...~!@#$%^&*

在IDE工具方面不断在改进升级，但在语言的表达能力上一直停滞不前。在对诸如接口支持和类型规则等的等待上，太让人失望，要不是看在java和C#都使用虚拟机的份上，就要一狠心完全转过去了。

Delphi先天营养太足，后天消化不良！

Delphi先天营养太足，后天消化不良！
-----------------------------------
这个猛...确实有点，且现在创新太少，总感觉有些 “旧”...

我只知道这东西能用，有什么想法基本都能实现。语法慢慢地适应了C再好但没有一个这么好的IDE,自己还可以做第三方控件。 PS:好像没有delphi这个语言，delphi是一个总称。
---------------------------------------------------------------------
好像从 D5 开始，Borland 已宣称 Delphi 是一“语言”了---不过大家还是习惯叫 “Object Pascal”...

其实对线程独立使用内存管理器的做法,相对应对线程的管理要求是相对过高的,并且还需要相应的配合.
首先,必须在线程的生命周期内完成内存的管理,这一点相对可控性是比较差的,任何时候一个线程都有可能被外部线程甚至是内部执行代码结束掉.如此,很大部分人都不推荐,甚至是警告性地要求程序员,尽可能不在线程内做非内存管理,包括了动态内存的分配和释放,因为在这当中风险是未知的.不管你的线程执行速度有多快,还是有可能在你刚申请完一大块内存之后被第二者给杀死,除了安全系统,谁也无法监控类似事件,除了操作系统,谁也无法阻止这一情况的发生;其次,就是我上面提到的,当各线程数量过多(甚至只要不是稀缺)的情况下,都有可能会闲置一部分线程,而那部分线程并不能保证之前的工作状态一直都是闲置的,如此可能会在之前分配了大量的内存,而此时这些内存却冗余地闲置着,虽然说现在的系统内存并不是一项瓶颈,但也并不是任何时间都会有过于冗余的内存配置,甚至在某些情况下,特别是内核态,那样内存稀缺的情况下,这就会是一个非常严重的问题.有个叫做线程亲缘性(亲缘性,即指定线程会在哪些CPU单元上面执行)分组,利用这个组别关系来进行内存管理,这样子由于在单一CPU单元上面并行冲突性较小(并不是没有),从而减少线程之间的竞争来来取取效率,如果可以通过均衡管理来调节各CPU单元的负载来达到合理的利用,虽然这个也存在线程级内存管理所存在的问题,但是多少了相当的改善;另一种,则也是我前面有提及的,采用主内存管理器加辅、协内存管理器模式的多内存管理器机制，从而分担了竞争压力，并且集中管理，并且可以通过算法级来达到最优的管理方案。虽然较前面的管理方案来说，性能可能会稍低一些，但是对于资源的利用，却相对要提高不少。据称CodeGear在新版的BDS当中，将会推出对多线程支持更好的开发环境，估计更优越地内存管理机制也会考虑在其中。不过综合来说，对应于高服务质量的系统，应用级的内存管理还是可以省去的。特别对于频繁使用的内存（包括对象、数据结构等）需要尽可能地重复利用，而减少生成（内存申请）和消毁（内存释放）所带来的系统消耗。毕竟对于一个通用的开发平台来说，它并不知道我们有哪些地方，哪些资源是需要重复利用的，虽然在很多地方，比如数据库访问等，已经给我们做了“池”的应用，那么同样的我们也应当要更好地去充分发挥这种处理方案，以期达到我们相应的目标。上面还有几位朋友提到Delphi语言本身，从个人观点，我并不强求别人来接受Delphi/Object Pascal这门开发语言，以及当前相对应的开发环境。语言也是一种环境，而任何环境，包括你生活所处的这个环境，所提供给你的资源同样有限。为什么别人可以在跟你同等有限的资源环境当中做也比你高出好几倍的成绩？关键点并不在于别人拥有更多的资源，而是在于他们更好地利用了资源。创新是一种需要，但是并不是必须。之所以环境本身需要升级，是这个环境本身也具有它自己的生命周期，当它的支持者创造者预见它还有更长的生命周期的时候，就会去改善它，于是适者生存，它也就存活下来了。但是，要知道的是，所有它的使用者，都是置后的，意思也就是，你所认识的永远都只是它的存在性，而不是预见性，而你所能利用的，所要利用的也是它的存在性。它仅仅只是你的一道工具，事实上它的发展与否确实对你造成了相当的不便利，但是却非它作为根本性而造就的。它跟不上社会地发展，而造成它的不足，并不代表它故意制造不足。换过来你也可以这样子想一下，如果它是一个万能的东西，那么这世界上还会有它的同等产品存在吗？或者说如果它的同等产品是一个万能的东西，你还会使用它吗？或许它的生命周期也由于结终了吧？！

另外，我想问一下楼上的各位兄弟姐妹们，有多少人有使用过Delphi 2007当中语言本身的新特性？
比如操作符重载，比如模板（有点貌似ＳＴＬ的味道）等等．

好久不用D了，先说说以前的1. Unicode支持不知道怎么样了？
2. 用D做ActiveXForm还会有默明奇妙的AV错误么？
3. 支持泛型了吗？
4. 反射支持的怎么样了？不要总是RTTI，太原始了总体感觉D在Win32桌面下，很强了，现在大部分是在吃老本 -_-||

楼上看来也是转到C# 或 Java去了和我一样。
作了半年的C# Winform程序。现在又回归到Delphi旗下了。
当时因为Unicode的问题放弃了Delphi（也解决了当时费了好大的事）
后来经过研究找到了一种更容易的方案，无缝的支持Unicode哦至于泛型这个就是语言支持不足的问题了现在发现Delphi版本出来一个又一个但是语法还是那么点
Borland发展没有后劲了。

还有发现CSDN支持Ajax了哈哈顶一个

我不牛人，但上大学学pascal的，所以

DELPHI 对 DDK的支持不是太多，而VC在开发这方面处于技术前沿！
奇怪的是DELPHI完全可以任用DDK，只是资料大少了。就“冰点”而言就是DELPHI开发的，可是编译一个SYS总要用MIS的工具！

Delphi最大的不足就是无法让使用dotnet和jave的公司转向Delphi

549 说的是个很主要的点delphi的功能定位就决定了他的市场范围MS 从 Web到System到Service到Win32到PDA等等有一揽子的解决方案，一气合成Java 有 J2ME/J2EE/J2SE 夸平台等等一揽子解决方案，也一气合成Borland的delphi和delphi.net有多大范围的市场可以利用？人都会选择市场前景更广阔的东东，不会从广阔返回到小范围市场应用中去 -_-|||

这帖子开得烂,"哪位牛人能跟我讲讲DELPHI语言的不足之处,越全越好!谢谢!"啥意思呢？
不想用Delphi就滚出去，来这里搞三搞四干什么。

发表于：2007-08-23 07:46:27 42楼得分:0
这帖子开得烂,"哪位牛人能跟我讲讲DELPHI语言的不足之处,越全越好!谢谢!"啥意思呢？
不想用Delphi就滚出去，来这里搞三搞四干什么。
---------------------------------------------
支持!Delphi 现在而言,在某些方面确实有些落后,在.NET方面比不上"后生"C#,如果你嫌不好, 你不可以不用啊. 而且估计你也不是从BORLAND正版买来的.

感觉Delphi在win32桌面下的确是很好了，不过不知道接下来的路好不好走，近些年的Delphi好像让人耳目一新的重大创新好像不太多。在Borland产品卖得最好的时候，都是引领着技术潮流的时候，Turbo Pascal、Borland C++、Delphi、JBuilder莫不如是，但当错误的战略导致人才这种最宝贵的企业资源相继流失的时候，这种辉煌还能重现吗？

Delphi最大不足：
1。工具较贵，如果你购买正版的话，否则用来开发产品有侵权风险。
2。没有Java的跨平台能力。
3。VC和C#属微软嫡系，Delphi日趋弱势。
4。用Delphi给公司的技术部门贴了入门级的标签，表示实力不济。
5。用Delphi给程序员贴了入门级标签，即便你自认水平很高。
6。虽然是WIN32的宠儿，逐渐被.NET遗弃。

4。用Delphi给公司的技术部门贴了入门级的标签，表示实力不济。
5。用Delphi给程序员贴了入门级标签，即便你自认水平很高。
6。虽然是WIN32的宠儿，逐渐被.NET遗弃。
=================
所谓使用Delphi就觉得是入门级，那有两种原因，一是啥也不懂的那种只会夸夸其谈的那种人才有如此的思想，二是因为确实有很多人只会拖拖控件就到处炫耀自己有如何如何编程能力，而招人口舌，从而冲淡了Delphi程序的意向含金量.Dot Net是一个在虚拟机平台当中执行的托管代码，最近几年不可能会完完全全地替代掉本地代码。

看了半天.缺点在人身上.工具无错,语言无错.错在自己.什么狗屁跨平台了,不要拿这吓唬人.....JAVA跨,Delphi 也可以,D7里一切换照写.照你这鸟样,他妈的 JAVA 能写手机游戏，你还怨Delphi语言差,工具破.看你这帖气不打一处,过阵子我发布一个Delphi 编写,能在手机上运行的游戏....傻蛋太多，怨天怨地....惟独自己好象没有错????!!!!!

至于质疑能否用Delphi 写手机游戏的,星级就不要质疑了.角类的可以质疑,我当看不见.路是人走出来的,什么都给你弄好了.看看C#,ASP.NET的薪资.一年不如一年.路边大树倒下去,砸死了10个程序员,5个学C#的.4个搞JAVA的 1个Delphi的. C++,C,脚本兄弟出来都很少，所以几率低.砸不到

Delphi7 不支持类变量，Delphi2007可以Delphi2007以前不支持泛型.据说D2009支持，没用过

delphi写小东西还行
我做的几个若干项目证明delphi不可大用，不可做服务器。
否则死都不知道怎么死的。
我写程序不用第三方组件，都是delphi自带的。详细注意了内存创建释放等东西。结果还是三天两头的死机，反观我写的java和.net、VC的程序运行几个月都没问题。
delphi不可大用

tcp+数据库+多线程的服务器大家千万别拿delphi写这样的程序了，性能太差。改成.net后几个月都不死机

delphi不好的地方就是用的人没C++，java等的多。而她又是如此实用优美。

delphi最大的不足就是到现在我都还没学会

过来做板凳学习的
支持Delphi..........!

我希望delphi 能和ICE 结合开发企业级广域网的分布式，不是局域网的分布式！希望delphi的网络支持更优秀！

死机的原因，是你对于对象还是没有了解透彻，还有变量的种类也有影响。到头来还是你水平的原因，我也会C#，他不会死机的原因是因为他跟操作系统的结合性太好，但是delphi的优势比C#多多了，起码C#的内部代码你看不到吧

delphi写服务器端老是死机，真搞笑。哈哈。

Delphi先天营养太足，后天消化不良！

估计，10年前，一般天才把DELPHI带到一个比较高的高度，其中一些创新的概念在目前还
处于领先。不过，之后几年，天才没了，DELPHI变得跟着微软跑了，OBJECT PASCAL一直变化不大。缺点：
1、一套代码能跨平台编译运行这比较弱。（或许我孤陋寡闻）
2、WEB开发的案例太少，造成WEB开发比较困难。
3、工具及第三方支持比较贵。优点：
1、WIN32开发王者。
2、支持开发的应用类型最广，比C#、JAVA、C++、C等都要广。
3、语言简洁严谨，编译速度快。第三方控件众多。
4、入门容易。
...

我这边Delphi 写的服务器稳定的很，只要程序是正确的，基本上没问题。。

oooO ↘┏━┓ ↙ Oooo
( 踩)→┃你┃ ←(死 )
\ ( →┃√┃ ← ) /
　 \_)↗┗━┛ ↖(_/

说明你的delphi学的太好了，都能达到三天两头的死机的水平了，
据我了解，某上市公司给证券写的交易平台的早期版本都是d版的，如果他们的写的程序也达到你那样的水平的话，估计证券公司的员工都已经跳楼了。

调试易

哪位牛人能跟我讲讲DELPHI语言的不足之处,越全越好!谢谢!

解决方案 »