B Bahl Unregistered / Unconfirmed GUEST, unregistred user! 2002-06-25 #81 to 教父: 您说虚函数与父类与子类有关系,但在C++中假设一个类没有父类,而我有意在类的构造函数上加上virtual呢?
I idl Unregistered / Unconfirmed GUEST, unregistred user! 2002-06-25 #83 哎,真让人沮丧!好象一本也没看过。以前学c++,vc时,都没看过。现在整天用delphi, 就更没心思去看c++的这些书了。因为现在我连Delphi都没学好,只会做一些简单的东西。 不过,说实在的,我一直就不明白为什么大家总认为c++比Delphi高出一筹?难道Delphi 就不是面向对象?我觉得只是由于历史的原因,c++应用的比delphi广而已。就象现在还 有很多很多人用c,甚至用cobol,因为由于某种原因,它们更加适合罢了。
哎,真让人沮丧!好象一本也没看过。以前学c++,vc时,都没看过。现在整天用delphi, 就更没心思去看c++的这些书了。因为现在我连Delphi都没学好,只会做一些简单的东西。 不过,说实在的,我一直就不明白为什么大家总认为c++比Delphi高出一筹?难道Delphi 就不是面向对象?我觉得只是由于历史的原因,c++应用的比delphi广而已。就象现在还 有很多很多人用c,甚至用cobol,因为由于某种原因,它们更加适合罢了。
B Bahl Unregistered / Unconfirmed GUEST, unregistred user! 2002-06-25 #86 只要你在C++的构造函数前加上virtual,不管它有没有父类子类都不能编译通过。 清华的《C++程序设计》没有说错。
左 左轻侯 Unregistered / Unconfirmed GUEST, unregistred user! 2002-06-25 #87 Bahl: 看了你的回答,我觉得你确实没有正确地了解问题的本质。 清华的《C++程序设计》的话,可以说是模模糊糊,并没有 说到问题的点子上。我怀疑作者本人也未必明白。C++的创 始人Bjarne Stroustrup在一个FAQ中,对这个问题有过权威 的回答: “虚拟调用是一种能够在给定信息不完全(given partial information)的情况下工作的机制。特别地,虚拟允许我们 调用某个函数,对于这个函数,仅仅知道它的接口,而不知 道具体的对象类型。但是要建立一个对象,你必须拥有完全 的信息。特别地,你需要知道要建立的对象的具体类型。因 此,对构造函数的调用不可能是虚拟的。” 我对这段话的理解是: 虚拟调用就是通过一个基类类型的指针,来调用派生类对象 的相应方法,其实际行为由派生类对象的类型来决定。因此, 指针指向不同的派生类对象时,可以得到不同的结果。但是, 构造函数则与此不同,它的调用本来就是要创建一个对象, 因此如果构造函数为虚拟的话,即意味着要“根据它创建的 对象的类型来决定它创建的对象类型”。这在逻辑上根本就 是悖论。 我正在翻译B.S的这个FAQ,你可以到我的主页上看看: http://www.wushuang.net 要说明的是,这个悖论不但在C++中存在,在Delphi中也同样 存在。基于这种思路的“虚拟构造函数”是不可能的。 你对Delphi中的虚拟构造的理解是不对的。我翻了一下《D5 开发人员指南》的59页。 首先,书中说的是“TFooObject已经静态地存在于内存中”, 而不是“对象TFooObject已经静态地存在于内存中”。TFooObject 是类,而不是对象。这很正常,C++中也是一样。书中也同时 指出,变量FooObject在调用时仍然没有定义。这也和C++ 中一样。 其次,这个范例跟虚拟调用毫无关系。它的本质是在对象没有 创建的时候,调用类中的一个静态方法。这也很正常,和C++ 也是一样的。 至于Delphi中为什么能够做到“虚拟构造”,那是因为Delphi 中的“类类型”概念,它不是“通过对象的类型来决定创建 的对象类型”,而是“通过类的类型来决定创建的对象类型”。 本论坛已经对此有过不少讨论,例如 http://www.delphibbs.com/delphibbs/dispq.asp?lid=1047021 虽然误解迭出,但基本上还是说到问题的本质了。 干脆说明一下我为什么用C++的书籍来做这个调查。 我用一种很简单(并不是很全面)的标准来衡量Delphi程序员, 那就是对Delphi的对象模型机制的了解。如果只是在Delphi的 对象级折腾,那么无论学过多少语法,做过多少工程,在某种 程度上也仍然没有走出新手的范围。只有透过Delphi的Interface, 深入到它的底层实现,才能够说是真正了解Delphi的开始。 而如你所说,现在市面上几乎没有深入讨论Delphi对象模型的 书籍,包括Master Delphi X、Delphi X Unleashed这样的名著, 都是偏向应用的。我见过的所有的朋友,都是从C++的对象模型 出发来了解Delphi的,而且几乎都多多少少犯过用C++套Delphi 的错误。而一个了解C++对象模型的人,却对上述书籍一无所知, 这是不可思议的。 如果说,有人对Delphi的对象模型了如指掌,而又对C++毫无 所知,这当然不是不可能,但可能性毕竟太小了。 Delphi程序员常常被人看不起,我觉得很多时候是自找的。
Bahl: 看了你的回答,我觉得你确实没有正确地了解问题的本质。 清华的《C++程序设计》的话,可以说是模模糊糊,并没有 说到问题的点子上。我怀疑作者本人也未必明白。C++的创 始人Bjarne Stroustrup在一个FAQ中,对这个问题有过权威 的回答: “虚拟调用是一种能够在给定信息不完全(given partial information)的情况下工作的机制。特别地,虚拟允许我们 调用某个函数,对于这个函数,仅仅知道它的接口,而不知 道具体的对象类型。但是要建立一个对象,你必须拥有完全 的信息。特别地,你需要知道要建立的对象的具体类型。因 此,对构造函数的调用不可能是虚拟的。” 我对这段话的理解是: 虚拟调用就是通过一个基类类型的指针,来调用派生类对象 的相应方法,其实际行为由派生类对象的类型来决定。因此, 指针指向不同的派生类对象时,可以得到不同的结果。但是, 构造函数则与此不同,它的调用本来就是要创建一个对象, 因此如果构造函数为虚拟的话,即意味着要“根据它创建的 对象的类型来决定它创建的对象类型”。这在逻辑上根本就 是悖论。 我正在翻译B.S的这个FAQ,你可以到我的主页上看看: http://www.wushuang.net 要说明的是,这个悖论不但在C++中存在,在Delphi中也同样 存在。基于这种思路的“虚拟构造函数”是不可能的。 你对Delphi中的虚拟构造的理解是不对的。我翻了一下《D5 开发人员指南》的59页。 首先,书中说的是“TFooObject已经静态地存在于内存中”, 而不是“对象TFooObject已经静态地存在于内存中”。TFooObject 是类,而不是对象。这很正常,C++中也是一样。书中也同时 指出,变量FooObject在调用时仍然没有定义。这也和C++ 中一样。 其次,这个范例跟虚拟调用毫无关系。它的本质是在对象没有 创建的时候,调用类中的一个静态方法。这也很正常,和C++ 也是一样的。 至于Delphi中为什么能够做到“虚拟构造”,那是因为Delphi 中的“类类型”概念,它不是“通过对象的类型来决定创建 的对象类型”,而是“通过类的类型来决定创建的对象类型”。 本论坛已经对此有过不少讨论,例如 http://www.delphibbs.com/delphibbs/dispq.asp?lid=1047021 虽然误解迭出,但基本上还是说到问题的本质了。 干脆说明一下我为什么用C++的书籍来做这个调查。 我用一种很简单(并不是很全面)的标准来衡量Delphi程序员, 那就是对Delphi的对象模型机制的了解。如果只是在Delphi的 对象级折腾,那么无论学过多少语法,做过多少工程,在某种 程度上也仍然没有走出新手的范围。只有透过Delphi的Interface, 深入到它的底层实现,才能够说是真正了解Delphi的开始。 而如你所说,现在市面上几乎没有深入讨论Delphi对象模型的 书籍,包括Master Delphi X、Delphi X Unleashed这样的名著, 都是偏向应用的。我见过的所有的朋友,都是从C++的对象模型 出发来了解Delphi的,而且几乎都多多少少犯过用C++套Delphi 的错误。而一个了解C++对象模型的人,却对上述书籍一无所知, 这是不可思议的。 如果说,有人对Delphi的对象模型了如指掌,而又对C++毫无 所知,这当然不是不可能,但可能性毕竟太小了。 Delphi程序员常常被人看不起,我觉得很多时候是自找的。
A Adnil Unregistered / Unconfirmed GUEST, unregistred user! 2002-06-25 #90 应该就是RTTI中的虚方法表有没有创建的问题了,C++的构造函数和Delphi的构造函数实现 方法有所区别。
X xmh_31 Unregistered / Unconfirmed GUEST, unregistred user! 2002-06-26 #92 左师兄的话,大家千万不要当真,或者要听听弦外之音。 左兄或者近来看了一些C++方面的书,有感而发,深感C++书中对OOP思想的论述对 深入编程益处颇大(不仅仅对delphi程序员),于是在此处卖关。不明所以的人慌乱跟 帖,有些甚至没了底气,失了信心,怕是左兄始料不及。 还好,没有引起C++ VS DELPHI大战,真幸事也。 闲来无事,胡诌几句,添些人气。 C++ > DELPHI > PB > VB (> 读作“看不起”,顺序或者有误),此观点由来已久 似乎不必理会。是人,便会被看不起,但是看不起未必有道理。前些天,在大街上,地下 管道漏水,众人绕行,仅有一衣衫褴褛之人,俯下身去痛饮,众人皆笑之。我心中一禀, 此真人也,现代文明使我们失去很多,唯此人依然拥有,令人肃然起敬。我们仅仅是写写 程序,既没有必要看不起别人,也不必在意别人看不起。 从来就没有什么奴隶,也没有什么救世主。千万别信有什么编程高手,“我亦无他, 唯手熟耳”。其实你只要在这行干,过你年,别人就会认为你是高手(只要你自己不这样 认为就行了)。别学什么东方不败,欲练神功,引刀自宫。 入界益缓,不要学什么都火急火燎的。一猛子扎到水里,一定得出来换口气,小心憋死 别把编程当成你的全部,视野要开阔。没事的时候(千万别说没这儿时候),可以看看星星, 侃侃足球,走到街上,多注意外部世界,尤其漂亮美媚,多瞟几眼,也满足一下人家的虚荣 心(停止!别盯着恐龙看,太残忍)。即使明天要交工,今天晚上也要睡个好觉,这是你的 权利。 别以为你会编程序,就有什么了不起,你仅仅是一台机器........ 真心的希望有一天,你大声的说: TMD,老子不干了。
左师兄的话,大家千万不要当真,或者要听听弦外之音。 左兄或者近来看了一些C++方面的书,有感而发,深感C++书中对OOP思想的论述对 深入编程益处颇大(不仅仅对delphi程序员),于是在此处卖关。不明所以的人慌乱跟 帖,有些甚至没了底气,失了信心,怕是左兄始料不及。 还好,没有引起C++ VS DELPHI大战,真幸事也。 闲来无事,胡诌几句,添些人气。 C++ > DELPHI > PB > VB (> 读作“看不起”,顺序或者有误),此观点由来已久 似乎不必理会。是人,便会被看不起,但是看不起未必有道理。前些天,在大街上,地下 管道漏水,众人绕行,仅有一衣衫褴褛之人,俯下身去痛饮,众人皆笑之。我心中一禀, 此真人也,现代文明使我们失去很多,唯此人依然拥有,令人肃然起敬。我们仅仅是写写 程序,既没有必要看不起别人,也不必在意别人看不起。 从来就没有什么奴隶,也没有什么救世主。千万别信有什么编程高手,“我亦无他, 唯手熟耳”。其实你只要在这行干,过你年,别人就会认为你是高手(只要你自己不这样 认为就行了)。别学什么东方不败,欲练神功,引刀自宫。 入界益缓,不要学什么都火急火燎的。一猛子扎到水里,一定得出来换口气,小心憋死 别把编程当成你的全部,视野要开阔。没事的时候(千万别说没这儿时候),可以看看星星, 侃侃足球,走到街上,多注意外部世界,尤其漂亮美媚,多瞟几眼,也满足一下人家的虚荣 心(停止!别盯着恐龙看,太残忍)。即使明天要交工,今天晚上也要睡个好觉,这是你的 权利。 别以为你会编程序,就有什么了不起,你仅仅是一台机器........ 真心的希望有一天,你大声的说: TMD,老子不干了。
房 房客 Unregistered / Unconfirmed GUEST, unregistred user! 2002-06-26 #93 xmh_31兄所言虽有些极端和偏激,但也有些道出了我所想。。(当然不是最后一句[]) 编程是一门技术,是一个现代道士的法术而已 是控制在几个大法家手中实施全球技术侵略的巫术 C++再高明的地方,再玄妙的地方多年后必将被视为SIMPLE 为什么? 看看人类的发展史吧 编程技术的发展同样需要简单为美,繁久必简,简久必繁。。 我们再来看看一些行情,或许不太正确。。 1。复杂技术的推行正在遭遇前所未有的阻力。。因为生产力和开发(不是编程)成本不成比 2。信用卡技术至尽推行50年,至尽未完全实现一卡走天下,再过 50年又会如何?。。计算机技术同理。。 3。计算机技术是科学,是要更大影响、刺激人类进步才能再造前几年开发膨胀的割据 4。为什么中国那么多高智商的整天研究别人的技术而乐此不疲?因为这些人EQ不高,一开始就对自己和别人说: “这个我(我们)不行,因为我们在中国,我们是中国人” 5。C++将被另一智能化高生产力语言代替,但至尽不知道这样的语言是不是中国人发起。。 6。。。。 最后。。 我们还有很多事情要思考
xmh_31兄所言虽有些极端和偏激,但也有些道出了我所想。。(当然不是最后一句[]) 编程是一门技术,是一个现代道士的法术而已 是控制在几个大法家手中实施全球技术侵略的巫术 C++再高明的地方,再玄妙的地方多年后必将被视为SIMPLE 为什么? 看看人类的发展史吧 编程技术的发展同样需要简单为美,繁久必简,简久必繁。。 我们再来看看一些行情,或许不太正确。。 1。复杂技术的推行正在遭遇前所未有的阻力。。因为生产力和开发(不是编程)成本不成比 2。信用卡技术至尽推行50年,至尽未完全实现一卡走天下,再过 50年又会如何?。。计算机技术同理。。 3。计算机技术是科学,是要更大影响、刺激人类进步才能再造前几年开发膨胀的割据 4。为什么中国那么多高智商的整天研究别人的技术而乐此不疲?因为这些人EQ不高,一开始就对自己和别人说: “这个我(我们)不行,因为我们在中国,我们是中国人” 5。C++将被另一智能化高生产力语言代替,但至尽不知道这样的语言是不是中国人发起。。 6。。。。 最后。。 我们还有很多事情要思考
L lance2000 Unregistered / Unconfirmed GUEST, unregistred user! 2002-06-26 #94 偶读的两本c++的书 一本是钱能写的,入门很不错! 一本就是think in c++ 当然两本书都看了不止两遍。 delphi程序员要想提高,不看c++的书几乎是不可能的!
教 教父 Unregistered / Unconfirmed GUEST, unregistred user! 2002-06-26 #95 惭愧啊惭愧,请问左兄,如何加深对Delphi的对象模型机制的了解?市面上确实找不到此类 的书。 我不认为追求技术细节有什么不好,如果你不能掌握C++或是OP的本质,你就很难自由自在 地使用他们。 我一直不能想象一个不擅写代码的程序员能成为一个好的系统分析员。那些不求甚解、逃避 难点的显然是对自己的不负责任,缺乏对编程技术的热爱,纯粹把编程做为饭碗而已。 >>Delphi程序员常常被人看不起,我觉得很多时候是自找的。 对于这句话,唉,真的不知道怎么说,其实大多时候不是Delphi被瞧不起,而是用Borland的 东西人被用MS的人瞧不起。我们公司有一个项目是用BCB做的,那些人都称自己以前是用VC的, 个个都说BCB如何地差,如何地不方便,却从来没有想过自己才只用了个把月的BCB。 我也问过这些自称VC程序员上述的问题,却没有一个人能说得清楚的,很多人说没有看得这 么细,有一个天天叫着BCB有BUG,VC就不会出现这种问题的人更是声称C++的构造函数可以是 虚函数,但就是这样的人,他仍然瞧不起象Delphi这样的工具,你说,我们能怎么办? Delphi无罪,RAD其罪也!如果Delphi一开始就弄得比VC还晦涩的话说不定会更流行了。
惭愧啊惭愧,请问左兄,如何加深对Delphi的对象模型机制的了解?市面上确实找不到此类 的书。 我不认为追求技术细节有什么不好,如果你不能掌握C++或是OP的本质,你就很难自由自在 地使用他们。 我一直不能想象一个不擅写代码的程序员能成为一个好的系统分析员。那些不求甚解、逃避 难点的显然是对自己的不负责任,缺乏对编程技术的热爱,纯粹把编程做为饭碗而已。 >>Delphi程序员常常被人看不起,我觉得很多时候是自找的。 对于这句话,唉,真的不知道怎么说,其实大多时候不是Delphi被瞧不起,而是用Borland的 东西人被用MS的人瞧不起。我们公司有一个项目是用BCB做的,那些人都称自己以前是用VC的, 个个都说BCB如何地差,如何地不方便,却从来没有想过自己才只用了个把月的BCB。 我也问过这些自称VC程序员上述的问题,却没有一个人能说得清楚的,很多人说没有看得这 么细,有一个天天叫着BCB有BUG,VC就不会出现这种问题的人更是声称C++的构造函数可以是 虚函数,但就是这样的人,他仍然瞧不起象Delphi这样的工具,你说,我们能怎么办? Delphi无罪,RAD其罪也!如果Delphi一开始就弄得比VC还晦涩的话说不定会更流行了。
L lql0459 Unregistered / Unconfirmed GUEST, unregistred user! 2002-06-26 #96 Design Patterns 但我现用java!
Z zswenyun Unregistered / Unconfirmed GUEST, unregistred user! 2002-06-26 #97 DELPHI也好,VC也好我到觉得只不过一种工具而已,一个人若对DELPHI或VC看不起只能说明 他对这个工具还不太了解,不管什么工具只要你用熟了,而它又没有过时那就是好东西。
X xx hh Unregistered / Unconfirmed GUEST, unregistred user! 2002-06-26 #98 我想请问左老师: 您说的:从C++的对象模型出发来了解Delphi的,而且几乎都多多少少犯过 用C++套Delphi的错误。 我的疑问就是:学Delphi的人,硬去看C++的理论或者说内核,这样不是容易范您 上述的错误吗。这样不是更混淆不清了吗。我是一名菜鸟,但执着的爱着编程这行事业, 而且现在正是有好些疑惑,不知如何才能提高。看到上面大家的各种评述,我更想搞清 一点,就是到底学C++对于提高或做一个Delphi高手有多大帮助。这两门语言不会冲突吗。 我想像我这样的"菜鸟"一定有很多,请您赐教!!!请各位高手赐教
我想请问左老师: 您说的:从C++的对象模型出发来了解Delphi的,而且几乎都多多少少犯过 用C++套Delphi的错误。 我的疑问就是:学Delphi的人,硬去看C++的理论或者说内核,这样不是容易范您 上述的错误吗。这样不是更混淆不清了吗。我是一名菜鸟,但执着的爱着编程这行事业, 而且现在正是有好些疑惑,不知如何才能提高。看到上面大家的各种评述,我更想搞清 一点,就是到底学C++对于提高或做一个Delphi高手有多大帮助。这两门语言不会冲突吗。 我想像我这样的"菜鸟"一定有很多,请您赐教!!!请各位高手赐教
W wukw Unregistered / Unconfirmed GUEST, unregistred user! 2002-06-26 #100 >> 左师兄的话,大家千万不要当真,或者要听听弦外之音。 左兄或者近来看了一些C++方面的书,有感而发,深感C++书中对OOP思想的论述对 深入编程益处颇大(不仅仅对delphi程序员),于是在此处卖关。不明所以的人慌乱跟 帖,有些甚至没了底气,失了信心,怕是左兄始料不及。 还好,没有引起C++ VS DELPHI大战,真幸事也。 闲来无事,胡诌几句,添些人气。 C++ > DELPHI > PB > VB (> 读作“看不起”,顺序或者有误),此观点由来已久 似乎不必理会。是人,便会被看不起,但是看不起未必有道理。前些天,在大街上,地下 管道漏水,众人绕行,仅有一衣衫褴褛之人,俯下身去痛饮,众人皆笑之。我心中一禀, 此真人也,现代文明使我们失去很多,唯此人依然拥有,令人肃然起敬。我们仅仅是写写 程序,既没有必要看不起别人,也不必在意别人看不起。 从来就没有什么奴隶,也没有什么救世主。千万别信有什么编程高手,“我亦无他, 唯手熟耳”。其实你只要在这行干,过你年,别人就会认为你是高手(只要你自己不这样 认为就行了)。别学什么东方不败,欲练神功,引刀自宫。 入界益缓,不要学什么都火急火燎的。一猛子扎到水里,一定得出来换口气,小心憋死 别把编程当成你的全部,视野要开阔。没事的时候(千万别说没这儿时候),可以看看星星, 侃侃足球,走到街上,多注意外部世界,尤其漂亮美媚,多瞟几眼,也满足一下人家的虚荣 心(停止!别盯着恐龙看,太残忍)。即使明天要交工,今天晚上也要睡个好觉,这是你的 权利。 别以为你会编程序,就有什么了不起,你仅仅是一台机器........ 真心的希望有一天,你大声的说: TMD,老子不干了。 精彩!!!
>> 左师兄的话,大家千万不要当真,或者要听听弦外之音。 左兄或者近来看了一些C++方面的书,有感而发,深感C++书中对OOP思想的论述对 深入编程益处颇大(不仅仅对delphi程序员),于是在此处卖关。不明所以的人慌乱跟 帖,有些甚至没了底气,失了信心,怕是左兄始料不及。 还好,没有引起C++ VS DELPHI大战,真幸事也。 闲来无事,胡诌几句,添些人气。 C++ > DELPHI > PB > VB (> 读作“看不起”,顺序或者有误),此观点由来已久 似乎不必理会。是人,便会被看不起,但是看不起未必有道理。前些天,在大街上,地下 管道漏水,众人绕行,仅有一衣衫褴褛之人,俯下身去痛饮,众人皆笑之。我心中一禀, 此真人也,现代文明使我们失去很多,唯此人依然拥有,令人肃然起敬。我们仅仅是写写 程序,既没有必要看不起别人,也不必在意别人看不起。 从来就没有什么奴隶,也没有什么救世主。千万别信有什么编程高手,“我亦无他, 唯手熟耳”。其实你只要在这行干,过你年,别人就会认为你是高手(只要你自己不这样 认为就行了)。别学什么东方不败,欲练神功,引刀自宫。 入界益缓,不要学什么都火急火燎的。一猛子扎到水里,一定得出来换口气,小心憋死 别把编程当成你的全部,视野要开阔。没事的时候(千万别说没这儿时候),可以看看星星, 侃侃足球,走到街上,多注意外部世界,尤其漂亮美媚,多瞟几眼,也满足一下人家的虚荣 心(停止!别盯着恐龙看,太残忍)。即使明天要交工,今天晚上也要睡个好觉,这是你的 权利。 别以为你会编程序,就有什么了不起,你仅仅是一台机器........ 真心的希望有一天,你大声的说: TMD,老子不干了。 精彩!!!