热
热血
Unregistered / Unconfirmed
GUEST, unregistred user!
建议看看boost ACE Loki Stl等C++类库再说C++吧
小
小猪
Unregistered / Unconfirmed
GUEST, unregistred user!
to:crane
呵呵，我最近正好在辅导一个远房的表弟，我给他的建议是先学c和数据结构，接下来
是vc，然后是java或者。net。还有，我的屁股小，你的马屁拍的我生疼。
to：all
为什么我们要纠缠于语言的差异究竟孰优孰劣？对于这个问题，我有自己的看法，但
我却不愿意在这里添一段口水，因为我认为这根本是毫无意义的。ddev的问题是c＋＋和
java的类构造方法和delphi为什么会不同，它们分别是出于什么样的考虑？也许王寒松
说的对：“蓝色的好， 严肃又庄重；红色的好， 鲜艳有活力”。
我对java有一些研究，c＋＋和delphi却是不过尔尔，单就java来说，我大概能说出一些
东西，却无从比较，因此很希望能看到有人能对此作一个深刻的比较。记得前年看到过
一个讨论，关于为什么c＋＋中构造函数不能为虚函数，而delphi中却可以，我没有看到
有人说c＋＋的方式好，也没有看到有人说delphi的方式好，看到的，只是无数高人精辟
的分析，说实话，我从中受益良多。
就我知道的，java的类构造机制同c＋＋还是有些不同的，但我对c＋＋和delphi实在没有
研究，我无法中比较得出为什么java和c＋＋要采用和delphi不一致的方式，这是为什么我
说我不知说些什么的原因。我也很希望有高人能解此疑问，我也希望，能从中学到一些我
原本并不知道的知识。
呵呵，我最近正好在辅导一个远房的表弟，我给他的建议是先学c和数据结构，接下来
是vc，然后是java或者。net。还有，我的屁股小，你的马屁拍的我生疼。
to：all
为什么我们要纠缠于语言的差异究竟孰优孰劣？对于这个问题，我有自己的看法，但
我却不愿意在这里添一段口水，因为我认为这根本是毫无意义的。ddev的问题是c＋＋和
java的类构造方法和delphi为什么会不同，它们分别是出于什么样的考虑？也许王寒松
说的对：“蓝色的好， 严肃又庄重；红色的好， 鲜艳有活力”。
我对java有一些研究，c＋＋和delphi却是不过尔尔，单就java来说，我大概能说出一些
东西，却无从比较，因此很希望能看到有人能对此作一个深刻的比较。记得前年看到过
一个讨论，关于为什么c＋＋中构造函数不能为虚函数，而delphi中却可以，我没有看到
有人说c＋＋的方式好，也没有看到有人说delphi的方式好，看到的，只是无数高人精辟
的分析，说实话，我从中受益良多。
就我知道的，java的类构造机制同c＋＋还是有些不同的，但我对c＋＋和delphi实在没有
研究，我无法中比较得出为什么java和c＋＋要采用和delphi不一致的方式，这是为什么我
说我不知说些什么的原因。我也很希望有高人能解此疑问，我也希望，能从中学到一些我
原本并不知道的知识。
L
Linman
Unregistered / Unconfirmed
GUEST, unregistred user!
我觉得，现在之所以推崇 Java 并不在于 Java 是一个优秀得不得了的语言，而是在于
建立在java之上的，由大量企业级世界级如Sun、IBM、HP等等公司实践、制订（或参与
制订）的应用规范，如EJB。这些应用规范，并不是语言级的东东，更多是设计思想应用
规范。移植到C# 照样也能行得通，这也是微软聪明的地方，搞个C#出来，Java 所积累的
思想文化，不用多大力气就可以移到C#上用。
delphi 所面向的开发群，是windows上的桌面开发。由于受到 windows 在企业应用支持
上的先天性缺陷，再加上只有Borland公司独国支持。在类似于J2EE这些应用规范的制订
上自然是有心无力，我们从delphi的发展，不断将第三方的东东纳入delphi就可以看得
出delphi的这种无奈。但，可以看得出，Borland在这方面是不断努力，先加入Bold for
delphi，到后面承诺加入Together，都是想走出一条适合delphi 的可行的应用规范。
微软推出.Net 其实是给 delphi 的发展一个非常大的机遇，面对于以往的MTS/COM+等等
要实现象J2EE那样的应用规范，那也实在难为Borland公司。但有了.Net 就不同，当微软
从系统级将企业级的应用环境完善和规范化后，根植于.net 环境之上的Delphi，我想其
前景和发展是如虎添翼的。。。。。。我并不是想帮Borland公司卖广告，只是想说说我
对Delphi 的看法而已。
建立在java之上的，由大量企业级世界级如Sun、IBM、HP等等公司实践、制订（或参与
制订）的应用规范，如EJB。这些应用规范，并不是语言级的东东，更多是设计思想应用
规范。移植到C# 照样也能行得通，这也是微软聪明的地方，搞个C#出来，Java 所积累的
思想文化，不用多大力气就可以移到C#上用。
delphi 所面向的开发群，是windows上的桌面开发。由于受到 windows 在企业应用支持
上的先天性缺陷，再加上只有Borland公司独国支持。在类似于J2EE这些应用规范的制订
上自然是有心无力，我们从delphi的发展，不断将第三方的东东纳入delphi就可以看得
出delphi的这种无奈。但，可以看得出，Borland在这方面是不断努力，先加入Bold for
delphi，到后面承诺加入Together，都是想走出一条适合delphi 的可行的应用规范。
微软推出.Net 其实是给 delphi 的发展一个非常大的机遇，面对于以往的MTS/COM+等等
要实现象J2EE那样的应用规范，那也实在难为Borland公司。但有了.Net 就不同，当微软
从系统级将企业级的应用环境完善和规范化后，根植于.net 环境之上的Delphi，我想其
前景和发展是如虎添翼的。。。。。。我并不是想帮Borland公司卖广告，只是想说说我
对Delphi 的看法而已。
W
wuliaotd
Unregistered / Unconfirmed
GUEST, unregistred user!
to 小猪：
你批评得对，不作无谓之争，下面希望Delphi Fans和我探讨探讨。
不构造基类对象的继承从理论上来说是违反面向对象原则的，解释如下：
“洗衣机”是一个基类，“某牌洗衣机”是一个派生类，从现实逻辑和编程理论来说，要生
产“某牌洗衣机”必然会生产出一个所有“洗衣机”都具有的功能和属性，对不对？这时我
们就说它构造了一个基类对象。然后某牌洗衣机再添加它特有的功能和属性，这些功能和属
性加上“洗衣机”都具有的功能和属性，一起叫做派生类对象。
Delphi的方法大概是不生产“洗衣机”，直接生产“某牌洗衣机”，事实上现实生活中也是
这样的，这种工作方式比前一种效率显然更高一些（Crane说的代码紧紧贴着需求走）。这
种方式是家庭中运行良好，在洗衣工厂中却不行了。
为什么呢？现在让我们假设一台洗衣机坏了，马上要换另一台；或者某一台运行良好的“某
牌洗衣机”需要搬到国外去洗衣，问题来了：“某牌洗衣机”只构造了“滚筒”，没有构造
“容器”，结果换一台洗衣机后洗衣工人还是去找“滚筒”，——哎呀呀！
同样的，运行良好的“某牌洗衣机”需要搬到国外去，它只配置了适合中国的插座，而没有
生产一通用的插座，结果它的电都通不了。
所以“古文明”存在的意义正如说明了Delphi对面向对象的支持不纯粹，不是强制性的，极
易构造非对象的编程和设计。包括前面列举的一些据说.NET和Java很难实现的一些特性，为
什么难以实现？是因为厂商不允许这么做，而不是实现不了。
你批评得对，不作无谓之争，下面希望Delphi Fans和我探讨探讨。
不构造基类对象的继承从理论上来说是违反面向对象原则的，解释如下：
“洗衣机”是一个基类，“某牌洗衣机”是一个派生类，从现实逻辑和编程理论来说，要生
产“某牌洗衣机”必然会生产出一个所有“洗衣机”都具有的功能和属性，对不对？这时我
们就说它构造了一个基类对象。然后某牌洗衣机再添加它特有的功能和属性，这些功能和属
性加上“洗衣机”都具有的功能和属性，一起叫做派生类对象。
Delphi的方法大概是不生产“洗衣机”，直接生产“某牌洗衣机”，事实上现实生活中也是
这样的，这种工作方式比前一种效率显然更高一些（Crane说的代码紧紧贴着需求走）。这
种方式是家庭中运行良好，在洗衣工厂中却不行了。
为什么呢？现在让我们假设一台洗衣机坏了，马上要换另一台；或者某一台运行良好的“某
牌洗衣机”需要搬到国外去洗衣，问题来了：“某牌洗衣机”只构造了“滚筒”，没有构造
“容器”，结果换一台洗衣机后洗衣工人还是去找“滚筒”，——哎呀呀！
同样的，运行良好的“某牌洗衣机”需要搬到国外去，它只配置了适合中国的插座，而没有
生产一通用的插座，结果它的电都通不了。
所以“古文明”存在的意义正如说明了Delphi对面向对象的支持不纯粹，不是强制性的，极
易构造非对象的编程和设计。包括前面列举的一些据说.NET和Java很难实现的一些特性，为
什么难以实现？是因为厂商不允许这么做，而不是实现不了。
J
James Martin
Unregistered / Unconfirmed
GUEST, unregistred user!
既然你看到了这里，嘿嘿：
http://www.delphibbs.com/delphibbs/dispq.asp?lid=632501
抱歉，楼主。[
]
http://www.delphibbs.com/delphibbs/dispq.asp?lid=632501
抱歉，楼主。[
]
B
Badlucky
Unregistered / Unconfirmed
GUEST, unregistred user!
愚以为：
编程工具其实是在表达自己的编程思想，而面向对象编程工具是在表达面向对象方法论，而面向对象思想在现在来说似乎已趋于稳定，也就是说这些工具比较起来已经不可能会有很大的突破和长处，只不过取舍不同而已。
勉强的相互比较也不过是那这个的长处比另一个的短处而已，所以永远没有争论的结果。
喜欢DELPHI因为它既有类型语言的长处又紧密的和操作系统接口“API”结合。
喜欢C++因为它的无拘无束和简洁。
不喜欢JAVA因为它倡导的所谓“跨平台”，只不过是构造了自己的平台而已，感觉这更象一个商业决定，而不是一个技术优势。
编程工具其实是在表达自己的编程思想，而面向对象编程工具是在表达面向对象方法论，而面向对象思想在现在来说似乎已趋于稳定，也就是说这些工具比较起来已经不可能会有很大的突破和长处，只不过取舍不同而已。
勉强的相互比较也不过是那这个的长处比另一个的短处而已，所以永远没有争论的结果。
喜欢DELPHI因为它既有类型语言的长处又紧密的和操作系统接口“API”结合。
喜欢C++因为它的无拘无束和简洁。
不喜欢JAVA因为它倡导的所谓“跨平台”，只不过是构造了自己的平台而已，感觉这更象一个商业决定，而不是一个技术优势。
W
wr960204
Unregistered / Unconfirmed
GUEST, unregistred user!
不知道为什么我不喜欢Java和.Net这种方式。我很喜欢直接进入系统底层。比如嵌入汇编，直接调用API。我觉得功能强大，使用灵活。
所以我更喜欢C++和Delphi这种类型的开发工具。
至于跨平台，我觉得Borland的做法不错。一套统一的CLX类库。两个编译器，分别生成两个平台上的原生代码。执行效率肯定比虚拟机要好上很多。
完全两种概念，Java是一次编译到处运行，而Kylix／Delphi却是一次编写到处编译。
各有好处。
当然我没有诋毁Java和.Net的意思。只是我更喜欢这种自由灵活方式。就向有人喜欢吃辣的，有人喜欢吃酸的一样。我只喜欢我那一种。
所以我更喜欢C++和Delphi这种类型的开发工具。
至于跨平台，我觉得Borland的做法不错。一套统一的CLX类库。两个编译器，分别生成两个平台上的原生代码。执行效率肯定比虚拟机要好上很多。
完全两种概念，Java是一次编译到处运行，而Kylix／Delphi却是一次编写到处编译。
各有好处。
当然我没有诋毁Java和.Net的意思。只是我更喜欢这种自由灵活方式。就向有人喜欢吃辣的，有人喜欢吃酸的一样。我只喜欢我那一种。
W
wuliaotd
Unregistered / Unconfirmed
GUEST, unregistred user!
to 李大嘴：
我上面在你之前就说了：“刚刚才开始支持。”
谁无知？我是一个性格很冲的人，看不来一些对面向对象一知半解的人胡乱的下结论。
1、你画UML图，我根据你的UML图写出Java代码；
2、我画UML图，你根据我的UML图写出Delphi代码；
3、你给出Java代码，我反向工程出UML图；
4、我给出Delphi代码，你反向工程出UML图。
反正Rose也支持Delphi，我也不占便宜。
（就算你是Rose高手，你不在第4项上死得很难看，我名字倒写！）
to all：
我只和李大嘴比，因为水平真的很菜。只能和六七年前水平比我好一点、目前退步厉害的李大嘴先生的小比一下。
我上面在你之前就说了：“刚刚才开始支持。”
谁无知？我是一个性格很冲的人，看不来一些对面向对象一知半解的人胡乱的下结论。
1、你画UML图，我根据你的UML图写出Java代码；
2、我画UML图，你根据我的UML图写出Delphi代码；
3、你给出Java代码，我反向工程出UML图；
4、我给出Delphi代码，你反向工程出UML图。
反正Rose也支持Delphi，我也不占便宜。
（就算你是Rose高手，你不在第4项上死得很难看，我名字倒写！）
to all：
我只和李大嘴比，因为水平真的很菜。只能和六七年前水平比我好一点、目前退步厉害的李大嘴先生的小比一下。
L
lynu
Unregistered / Unconfirmed
GUEST, unregistred user!
赞同linkman,其实在思想方面,各家已经赴向大同,只是各有实现与侧重不同
X
xeen
Unregistered / Unconfirmed
GUEST, unregistred user!
wr960204:只要你在 windows 平台下编程，不管你多么不喜欢.net，以后
都得面对它。MS 为了自己的策略肯定会在 windows 平台下打压那些原生
程序的空间.
都得面对它。MS 为了自己的策略肯定会在 windows 平台下打压那些原生
程序的空间.
J
James Martin
Unregistered / Unconfirmed
GUEST, unregistred user!
既然有不少高手，请大家解答了楼主的问题再走：
“
我们知道 C++ 采用由上到下的构造；而 Delphi 采用的是由下而上的构造。
因此，无论你愿意不愿意，在 C++ 中构造一个类时，你不得不去构造它的
祖类；而在 Delphi 中，你却可以选择性地 inherited 祖类的构造。我个
人觉得，这种模式应该更科学，原因是：如果我需要用祖类同样的参数来构造
一个类，但却要与祖类有完全不同的处理（同参数构想必肯定会是这种处理
要求），因此可以不 inherited；但在 C++ 中，无论你愿不愿意，你都得去
古文明时代走一圈，而现在，Java 却也采用这种“无选择”的构造，不禁要
问：
[blue]为什么 Java 要采用 C++ 的构造模式而不是 Delphi 的？！难道这种构造有
什么先进的地方吗？[/blue]
”
“
我们知道 C++ 采用由上到下的构造；而 Delphi 采用的是由下而上的构造。
因此，无论你愿意不愿意，在 C++ 中构造一个类时，你不得不去构造它的
祖类；而在 Delphi 中，你却可以选择性地 inherited 祖类的构造。我个
人觉得，这种模式应该更科学，原因是：如果我需要用祖类同样的参数来构造
一个类，但却要与祖类有完全不同的处理（同参数构想必肯定会是这种处理
要求），因此可以不 inherited；但在 C++ 中，无论你愿不愿意，你都得去
古文明时代走一圈，而现在，Java 却也采用这种“无选择”的构造，不禁要
问：
[blue]为什么 Java 要采用 C++ 的构造模式而不是 Delphi 的？！难道这种构造有
什么先进的地方吗？[/blue]
”
L
lynu
Unregistered / Unconfirmed
GUEST, unregistred user!
对于具体问题,我赞同wuliaotd的观点,还有我个人的看法也可算上.
李
李大嘴
Unregistered / Unconfirmed
GUEST, unregistred user!
"谁无知？"
java是纯面向对象,object pascal &
c++ 都是混合型 你连这个区别都不知道,还让别人画UML?
TObject -> TPersistent -> TComponent -> TControl -> TWinControl -> TButtonControl -> TButton
这叫直接生产"某牌洗衣机" ???
还玩什么挑战,搞了半天终于露出小尾巴来了,难怪你一直在歪曲DELPHI,合着是来踢馆的?
我不是一个性格很冲的人，但也"看不来一些对面向对象一知半解的人胡乱的下结论。"
java是纯面向对象,object pascal &
c++ 都是混合型 你连这个区别都不知道,还让别人画UML?
TObject -> TPersistent -> TComponent -> TControl -> TWinControl -> TButtonControl -> TButton
这叫直接生产"某牌洗衣机" ???
还玩什么挑战,搞了半天终于露出小尾巴来了,难怪你一直在歪曲DELPHI,合着是来踢馆的?
我不是一个性格很冲的人，但也"看不来一些对面向对象一知半解的人胡乱的下结论。"
B
Badlucky
Unregistered / Unconfirmed
GUEST, unregistred user!
个人认为：
采用C++的构造模式首先是保证了安全性，使得基类有了合理的初始化值。
但这样在子类不需要基类的初始化时这个步骤似乎就多余了，但是可以采取牺牲效率的方法子类在再重新初始化一遍基类。而这种情况应该是较少发生的，所以衡量安全性和效率我觉得应该采用C++的办法。
采用C++的构造模式首先是保证了安全性，使得基类有了合理的初始化值。
但这样在子类不需要基类的初始化时这个步骤似乎就多余了，但是可以采取牺牲效率的方法子类在再重新初始化一遍基类。而这种情况应该是较少发生的，所以衡量安全性和效率我觉得应该采用C++的办法。
W
wuliaotd
Unregistered / Unconfirmed
GUEST, unregistred user!
to James Martin:
为什么在我这个菜鸟看来这个问题很简单啊？
我在2083287帖中讲得象小学生课程一样，肯定许多高手都不愿意看了。
另外，“在 Delphi 中，你却可以选择性地 inherited 祖类的构造”是什么意思，我是否
在2083287帖中理解错了？
“我需要用祖类同样的参数来构造一个类，但却要与祖类有完全不同的处理（同参数构想必
肯定会是这种处理要求）”在Java中不是也是很简单的么？一个同参overriding，不同参overloading就完了嘛，有什么不好理解的问题？
烦请您老看一下，以免我还在这儿夜郎自大，如果我错了，得幸由高手指出，也算我在这个
帖子中赌气的收获，对不对？不然坐井观天，贻笑大方了，要是在现实生活中我肯定是要吃
大亏的，所以真心向你及其它高手请教。
为什么在我这个菜鸟看来这个问题很简单啊？
我在2083287帖中讲得象小学生课程一样，肯定许多高手都不愿意看了。
另外，“在 Delphi 中，你却可以选择性地 inherited 祖类的构造”是什么意思，我是否
在2083287帖中理解错了？
“我需要用祖类同样的参数来构造一个类，但却要与祖类有完全不同的处理（同参数构想必
肯定会是这种处理要求）”在Java中不是也是很简单的么？一个同参overriding，不同参overloading就完了嘛，有什么不好理解的问题？
烦请您老看一下，以免我还在这儿夜郎自大，如果我错了，得幸由高手指出，也算我在这个
帖子中赌气的收获，对不对？不然坐井观天，贻笑大方了，要是在现实生活中我肯定是要吃
大亏的，所以真心向你及其它高手请教。
W
wuliaotd
Unregistered / Unconfirmed
GUEST, unregistred user!
to 李大嘴：
你说是混合型的，但混合型的C++的面向对象支持得很好啊！你不是也说Delphi对面向对象
支持极优秀么？
好！我去掉第4项，我做两项你做一项，如何？
“在 Delphi 中，你却可以选择性地 inherited 祖类的构造”，是什么意思，恕我直言，
我是望文生义，真的，理解错了见谅。
另外，不要上纲上线好不好？
你说是混合型的，但混合型的C++的面向对象支持得很好啊！你不是也说Delphi对面向对象
支持极优秀么？
好！我去掉第4项，我做两项你做一项，如何？
“在 Delphi 中，你却可以选择性地 inherited 祖类的构造”，是什么意思，恕我直言，
我是望文生义，真的，理解错了见谅。
另外，不要上纲上线好不好？
H
hsb0307
Unregistered / Unconfirmed
GUEST, unregistred user!
大家看看SUN官方出版的一本书：《最新Java2核心技术卷I原理原书第5版》
她在第一章介绍java的简史时写道：
1.5 Java简史
本节介绍一下Java的简要发展史。参考资料来源于多方面，最主要的是1995年6月份的
SunWorld在线杂志上刊登的一篇[red]对Java创立者的采访[/red]。
Java的历史可以回溯到1991年，那时候一个Sun工程师小组，在Patrick Naughton和James Gosling（非常全面的计算机奇才）的领导下，着手设计一个小的能够用于像有线电视转换盒一类的消费设备的计算机语言。因为这些设备没有很强的处理能力和太多的内存，所以这个语言必须非常小并且能够生成非常紧凑的代码。还有，因为不同厂商可以选择不同的CPU，所以这个语言不能够限定在一个单一的体系结构之下，这是非常重要的。该项目称作“ Green”。
代码需要小、紧凑以及与平台无关。该项要求使得开发团队重新搬出了早期PC上尝试过的
一些Pascal实现模型。Niklaus Wirth—Pascal的发明者作为先驱者尝试把UCSD Pascal语言设计为一种能够为异构机器生成中间代码的可移植的语言（这常被称作虚拟机，相对应的就是Java虚拟机—JVM）。中间代码可以在任何安装有合适解释器的机器上使用。Green项目的工程师们也通过使用一个虚拟机来解决了他们的主要问题。
[blue]Sun的开发人员，都是些有很深的UNIX背景的家伙，所以他们的语言是基于C++而不是pascal。[/blue]并且，他们把该语言设计为面向对象的，而不是面向过程的。但是正如Gosling在采访中所说的那样，“毕竟，语言只是工具而非全部”。Gosling决定把这个语言称作“ Oak”（起名的原因估计是因为他非常喜欢自己办公室窗外的橡树）。Sun的人员后来发现Oak是已经存在的一门计算机语言的名字，因此他们把名字改成了Java。
本人对Java、OO、Delphi都是刚入门，来听课。
她在第一章介绍java的简史时写道：
1.5 Java简史
本节介绍一下Java的简要发展史。参考资料来源于多方面，最主要的是1995年6月份的
SunWorld在线杂志上刊登的一篇[red]对Java创立者的采访[/red]。
Java的历史可以回溯到1991年，那时候一个Sun工程师小组，在Patrick Naughton和James Gosling（非常全面的计算机奇才）的领导下，着手设计一个小的能够用于像有线电视转换盒一类的消费设备的计算机语言。因为这些设备没有很强的处理能力和太多的内存，所以这个语言必须非常小并且能够生成非常紧凑的代码。还有，因为不同厂商可以选择不同的CPU，所以这个语言不能够限定在一个单一的体系结构之下，这是非常重要的。该项目称作“ Green”。
代码需要小、紧凑以及与平台无关。该项要求使得开发团队重新搬出了早期PC上尝试过的
一些Pascal实现模型。Niklaus Wirth—Pascal的发明者作为先驱者尝试把UCSD Pascal语言设计为一种能够为异构机器生成中间代码的可移植的语言（这常被称作虚拟机，相对应的就是Java虚拟机—JVM）。中间代码可以在任何安装有合适解释器的机器上使用。Green项目的工程师们也通过使用一个虚拟机来解决了他们的主要问题。
[blue]Sun的开发人员，都是些有很深的UNIX背景的家伙，所以他们的语言是基于C++而不是pascal。[/blue]并且，他们把该语言设计为面向对象的，而不是面向过程的。但是正如Gosling在采访中所说的那样，“毕竟，语言只是工具而非全部”。Gosling决定把这个语言称作“ Oak”（起名的原因估计是因为他非常喜欢自己办公室窗外的橡树）。Sun的人员后来发现Oak是已经存在的一门计算机语言的名字，因此他们把名字改成了Java。
本人对Java、OO、Delphi都是刚入门，来听课。
X
xeen
Unregistered / Unconfirmed
GUEST, unregistred user!
构造函数是什么?是用来初始化对象的成员变量（field）的，它在对象分配完内存，并做一定初始化工作后调用，调用完成后返回一个新对象的引用，然后就可以使用这个对象了。
Delphi 其实也是调用标准的 C接口函数 malloc 来给对象分配内存的.
看看System 单元的代码:
function __malloc(Size: Integer): Pointer;
cdecl;
external libc name 'malloc';
VC里 new 出来的对象也是这样(不作运算符重载的情况下).
C++ 只不过强制规定了先依次初始化 base class成员（隐式调用base class构造函数），然后才是自己的成员。
Object 则不作此强制规定，对 base class 的构造函数的调用也是显式的(所谓 inherited create（.....
看见只不过Object Pascal 把初始化对象成员的方式与次序的选择权留给了程序员自己,
这之间的差别真的有那么大吗?
Delphi 其实也是调用标准的 C接口函数 malloc 来给对象分配内存的.
看看System 单元的代码:
function __malloc(Size: Integer): Pointer;
cdecl;
external libc name 'malloc';
VC里 new 出来的对象也是这样(不作运算符重载的情况下).
C++ 只不过强制规定了先依次初始化 base class成员（隐式调用base class构造函数），然后才是自己的成员。
Object 则不作此强制规定，对 base class 的构造函数的调用也是显式的(所谓 inherited create（.....
看见只不过Object Pascal 把初始化对象成员的方式与次序的选择权留给了程序员自己,
这之间的差别真的有那么大吗?
J
James Martin
Unregistered / Unconfirmed
GUEST, unregistred user!
果然不错，wuliaotd 早就提出了自己的观点:
针对
"
来自：ddev, 时间：2003-7-29 22:49:00, ID：2069437
我想这是由于类的构造所引起的：
Delphi 是单根构造，所以一个类的父总是可回溯的，也就是说：是确定的；
而 C++ 是多根构造，因此编译器/RTTI无法定位一个 inherited 的方向，因为它在
上溯过程中是发散的，如： / | /
/ | /
O
因此必须完整构造所有的父类，才能构造子类，这样子类的继承信息就确定了。
我说得对不对？
"
from wuliaotd:
"
3、你说得不对。基类对象（base object，不要和super关键字混为一谈，说父对象子对象是你理解上有误）是派生类对象（derived object）的子对象，包含于派生类对象之中，派生类往往需要访问基类的成员和方法，规定基类的构造函数首先初始化，是出于代码安全、减少bug上的考虑（Java出于代码安全方面的考虑而牺牲开发方便性和效率的地方还有很多）。它带来的的唯一不便之处是派生类无法捕捉基类构造函数的异常，你所举的例子，完全可以在构造派生类之前先行判断。
"
现在至少两个答案：
1、安全（支持人数较多）。
2、萝卜白菜各有所爱，c++/java/delphi 各自采用现在的处理方式，好像是一种偶然。
下班了，希望大家吃好饭，谁好觉，明天继续讨论，直到楼主满意。[
]
另外，wuliaotd，我是一只真的菜鸟。[
]
还有，这个贴子和2083287一模一样，怪了。
针对
"
来自：ddev, 时间：2003-7-29 22:49:00, ID：2069437
我想这是由于类的构造所引起的：
Delphi 是单根构造，所以一个类的父总是可回溯的，也就是说：是确定的；
而 C++ 是多根构造，因此编译器/RTTI无法定位一个 inherited 的方向，因为它在
上溯过程中是发散的，如： / | /
/ | /
O
因此必须完整构造所有的父类，才能构造子类，这样子类的继承信息就确定了。
我说得对不对？
"
from wuliaotd:
"
3、你说得不对。基类对象（base object，不要和super关键字混为一谈，说父对象子对象是你理解上有误）是派生类对象（derived object）的子对象，包含于派生类对象之中，派生类往往需要访问基类的成员和方法，规定基类的构造函数首先初始化，是出于代码安全、减少bug上的考虑（Java出于代码安全方面的考虑而牺牲开发方便性和效率的地方还有很多）。它带来的的唯一不便之处是派生类无法捕捉基类构造函数的异常，你所举的例子，完全可以在构造派生类之前先行判断。
"
现在至少两个答案：
1、安全（支持人数较多）。
2、萝卜白菜各有所爱，c++/java/delphi 各自采用现在的处理方式，好像是一种偶然。
下班了，希望大家吃好饭，谁好觉，明天继续讨论，直到楼主满意。[
]另外，wuliaotd，我是一只真的菜鸟。[
]还有，这个贴子和2083287一模一样，怪了。
李
李大嘴
Unregistered / Unconfirmed
GUEST, unregistred user!
在大富翁比的是谁能帮助更多的人
看你专家分才 0
脸红不脸红?
有空去帮别人回答问题
虽然我分不多,可怎么也不会瞎捣乱,
有种你年前专家分升到2000以上
我就承认你是作出了贡献
不然的话哪儿凉快哪儿呆着去
小孩子不务正业,懒得理你
看你专家分才 0
脸红不脸红?
有空去帮别人回答问题
虽然我分不多,可怎么也不会瞎捣乱,
有种你年前专家分升到2000以上
我就承认你是作出了贡献
不然的话哪儿凉快哪儿呆着去
小孩子不务正业,懒得理你