KeyFC欢迎致辞，点击播放
资源、介绍、历史、Q群等新人必读
KeyFC 社区总索引		 如果你找到这个笔记本，请把它邮寄给我们的回忆
KeyFC 漂流瓶传递活动 Since 2011		  

[M] Prelude to K.O. (4.5) + 12楼(4.75)

[ 14846 查看 / 31 回复 ]

返回列表 1234
发新话题 回复该主题
dwing
头像

  • - 千夏轮回的终点 -
  • 来自：
  • 性别：土豆
  • 生日：
  • 注册： 2007-03-08
  • 精华：0
  • 学分：0 个
  • 好人卡：30 张
  • 好感度：0
  • [帝都]
2007-06-12 09:26 |只看该用户 21#
t T

回复: [M] Prelude to K.O. (4.5) + 12楼(4.75)

汗,您讲的这些我并没有认同我说的有误,您对C++的理解和我对OP的理解半斤八两.我只好耐心地解释:

据我有限的理解，所谓的智能指针仅仅是保证在对象不再被引用的时候自动“析构”而已，和异常处理风马牛不相及，不用try...catch一样会挂。
如有错误，请纠正。

只要保证析构不抛出异常即可避免嵌套try...catch,析构不抛出异常这本来就是一条规定,就像判断指针是否为空之前不要随便赋值一样.C++的灵活使它能做到许多其他语言不能做到的很难想象的复杂功能,但也会出现滥用的后果,不能说核能危险我们就不去开发它.
VC的__try/__except机制才可以做到从出现异常的地方再次继续运行.不过我承认这个机制很危险,一般是没人用的.所以只有认为出现不可继续运行的严重问题时才抛出异常.

话说回来,delphi不也会面临层层套用try...catch的问题吗?

您可能没理解这句话的意思.
单层try...catch机制是不顾后果的,一旦抛出异常,异常后面的资源释放都无法继续执行,delphi怎么会避免呢?

这个时候如果发生异常，抛出的当然将是另一个的异常。

这就是我所说的一种情况,这里的"另一个异常"就没有前一个异常的信息了,用异常来调试也就"信息不完整"了.delphi构造任何异常都是要分配内存的,如果分配内存出现异常,则构造任何异常都会出错,最后即使能catch到,也只能得到分配内存错误的异常,而没有最初抛出的异常了.

如果程序遇到异常而可以不停止调试，那就证明程序可以继续运行下去，那么也就没有必要使用异常

这么说,异常就不是用来调试的.

(反映到实际使用中，比如分配、调用资源的失败，都可以用返回值，没有必要使用异常)；

呵呵,在实际使用中,异常经常用来解决"分配、调用资源的失败"而无法继续运行后面的代码,这些才是典型的"异常"并跳出,不必每次都判断返回值并做频繁的错误处理.如果出现一般错误,才应该用返回值.

我相信您的描述可以自圆其说，但是，你不能将自己的意愿强迫到别人的头上。别人怎么提供别人的实现，这是与您怎么实现您的对象是非常不同的事情。

合作写程序如果不做出一些规范,那才是灾难.

Delphi和C++异常处理对于一个人的几万行程序来说，基本没有区别。但是对于多人，特别是以松散方式合作的组来说，C++异常的scalability要差得多(这里的意思是，随着规模的扩大而导致可用性的快速降低)，这个是不争的事实。

天啊,您在哪里听说的无稽之谈,不妨给个参考让我好好拜读一下.没准我还真去"投靠"delphi了呢:)

但是问题是，无数的历史事实证明，独裁的结果肯定是快速灭亡，因此不是一个解决问题的办法。

C++是有标准并广泛存在的,delphi才有些独裁...这句话赠送给您更合适:)
最后编辑dwing 最后编辑于 2007-06-12 09:34:18
TOP
Prz
头像

千砂与美纱的神隐

  • - 根性组 -
  • 来自：国立万年小学校
  • 人家是女孩子的说
  • 生日：2003-06-01
  • 注册： 2002-09-18
  • 精华：15
  • 学分：0 个
  • 好人卡：40 张
  • 好感度：550
  • [爸爸国]
2007-06-12 11:13 |只看楼主 22#
t T

回复：[M] Prelude to K.O. (4.5) + 12楼(4.75)

只要保证析构不抛出异常即可避免嵌套try...catch,析构不抛出异常这本来就是一条规定,就像判断指针是否为空之前不要随便赋值一样.C++的灵活使它能做到许多其他语言不能做到的很难想象的复杂功能,但也会出现滥用的后果,不能说核能危险我们就不去开发它.
VC的__try/__except机制才可以做到从出现异常的地方再次继续运行.不过我承认这个机制很危险,一般是没人用的.所以只有认为出现不可继续运行的严重问题时才抛出异常.


模棱两可。请正面回答我的问题：您前篇里面企图把智能指针和异常处理混淆在一起，我认为是不相干的，我到底是错了还是对了？


单层try...catch机制是不顾后果的,一旦抛出异常,异常后面的资源释放都无法继续执行,delphi怎么会避免呢?


就用你自己的切身说法，析构仅仅是释放资源。那么异常发生，自然是比释放资源更严重的事情发生了，继续释放资源还有意义吗？
这个时候更妥善的解决办法是立刻中断下来，查找错误原因，而不是不负责任的写一句话到一个什么地方，继续作可能根本就是错误的事情，然后等一切都乱套以后，再对着屏幕发愣吧。


delphi构造任何异常都是要分配内存的，如果分配内存出现异常....


赫赫，请你不要天真地将自己不明白的东西愚蠢化。
象Out-of-memory这样的异常，如果不是提前预生成的，那就搞这个系统设计的人文凭一定是在什么菜市场买的.....

而且：
这就是我所说的一种情况,这里的"另一个异常"就没有前一个异常的信息了,用异常来调试也就"信息不完整"了


你用一个C++和Delphi以至于任何一种程序都会出现的问题，明显没有说明任何的作用。
举个简单的例子:
论题: 2007年生产的Core Duo的系统比1990年产的286性能优秀
你说: 将两台机器放在120摄氏度的烤箱，2分钟内两台机器都崩溃了，所以Core Duo系统并不比286好到哪里去
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||


这么说,异常就不是用来调试的


只要你不独裁，我尊重你的看法


呵呵,在实际使用中,异常经常用来解决"分配、调用资源的失败"而无法继续运行后面的代码


概念错误，"分配、调用资源的失败"绝对不是无法继续运行的错误。


合作写程序如果不做出一些规范,那才是灾难


因此对于异常处理规范性不佳的语言就不敢乱用异常。
就像知道自己不太能够控制用钱的人也就不会随便申请信用卡。
世界是理性的，广大人民是智慧的。


天啊,您在哪里听说的无稽之谈


知识爆炸的今天没有百科全书式的人物，可以理解。
使用Delphi的大中型项目中随处都找得到异常的使用；请找出使用C++的大中型工程中使用异常的例子？


C++是有标准并广泛存在的,delphi才有些独裁...这句话赠送给您更合适


我并没有叫嚣要强制规定别人怎么去编程，也没有叫嚣自己不喜欢的语言就要灭亡，因此相对您，我更不像独裁者。
哦，而且我也没有说是您是独裁者，那句话仅仅是对历史的反思，并不是送给谁的。
就像很久以前我批评"盗字"一样，和您一点关系都没有。
请您改掉喜欢对号入座的习惯，特别是看到负面的评价更是，不然这样不利于身心健康发展的。
飛べない翼に、意味はあるんでしょうか？
TOP
dwing
头像

  • - 千夏轮回的终点 -
  • 来自：
  • 性别：土豆
  • 生日：
  • 注册： 2007-03-08
  • 精华：0
  • 学分：0 个
  • 好人卡：30 张
  • 好感度：0
  • [帝都]
2007-06-12 11:53 |只看该用户 23#
t T

回复: [M] Prelude to K.O. (4.5) + 12楼(4.75)

模棱两可。请正面回答我的问题：您前篇里面企图把智能指针和异常处理混淆在一起，我认为是不相干的，我到底是错了还是对了？

智能指针的一个好处是能很好地处理异常时资源无法完全释放的问题.
在保证析构不向外抛出异常的情况下,借用智能指针的自动析构来释放资源是很安全便捷的.
而且也可在构造函数中抛出异常时自动释放资源.
而显式地释放资源就容易被try...catch机制忽略掉,而析构是不会忽略的.

就用你自己的切身说法，析构仅仅是释放资源。那么异常发生，自然是比释放资源更严重的事情发生了，继续释放资源还有意义吗？

我可不这么认为,如果真比释放资源还重要,那就像C++那样无法处理异常就退出好了.
例如我要读取文件中的内容并显示出来,这里就有可能出现许多无法继续执行的情况,如文件不存在,文件格式不正确,文件无法读取等等,
每次都写一堆if...else并且每次都要写一堆释放资源的代码是很烦琐的,这种情况就适合抛出异常,并在catch中统一释放资源.
这都不是致命错误,释放资源也是有意义的.

你用一个C++和Delphi以至于任何一种程序都会出现的问题，明显没有说明任何的作用。

我可没说C++在这个地方有优势,而是您说delphi有优势,而我反驳了而已,并没有C++在这个地方更好的意思.

只要你不独裁，我尊重你的看法

我可不是说要独裁,delphi的RAD是VC不及的地方,但要说写系统或底层程序,C/C++更适合.
(C/C++是能让编程者懂得每个步骤编译器是如何处理的对编程者要求比较高的语言.)
这不是我一个人的观点,而是事实上确实如此,我所见过的所有的操作系统,编解码器都使用ASM/C/C++,这是我"独裁"的结果吗?

概念错误，"分配、调用资源的失败"绝对不是无法继续运行的错误。

如果内存池无法分配,资源句柄无法分配,我想后面会有一大片代码无法继续运行了.

使用Delphi的大中型项目中随处都找得到异常的使用；请找出使用C++的大中型工程中使用异常的例子？

我见过许多写的很优秀的C++库都使用了异常,包括STL,BOOST,MFC等等.
在C++大中型工程中没遇到异常也是有许多原因的:
1.底层代码中很少遇到需要抛出异常的情况,像java那样高层语言,异常属于家常便饭了.
2.C++比较复杂,异常属于高级特性,非精通者不敢使用.
3.C/C++的工程许多都要考虑跨平台,而不可能保证异常一定被系统支持的.
4.使用异常容易使开发人员产生依赖感,对自己的代码不负责任.

因此相对您，我更不像独裁者

那么希望到开放接口时,不要像前面说的那样"CAS对于其它语言的兼容性并没有作太多妥协。"
(看看微软,虽然比较"独裁",但它的COM接口是非常开放的,从汇编到js脚本都能调用其接口.)
最后编辑dwing 最后编辑于 2007-06-12 12:02:02
TOP
Prz
头像

千砂与美纱的神隐

  • - 根性组 -
  • 来自：国立万年小学校
  • 人家是女孩子的说
  • 生日：2003-06-01
  • 注册： 2002-09-18
  • 精华：15
  • 学分：0 个
  • 好人卡：40 张
  • 好感度：550
  • [爸爸国]
2007-06-13 01:06 |只看楼主 24#
t T

回复：[M] Prelude to K.O. (4.5) + 12楼(4.75)

在保证析构不向外抛出异常的情况下,借用智能指针的自动析构来释放资源是很安全便捷的.
而且也可在构造函数中抛出异常时自动释放资源.


很遗憾的发现，你根本没有仔细阅读你自己在前面贴出来的那边CSDN的Blog。
构造异常的时候自动释放对象是Delphi的基本功能，不需要外加"智能"。


举个简单的例子:
论题: 2007年生产的Core Duo的系统比1990年产的286性能优秀
你说: 将两台机器放在120摄氏度的烤箱，2分钟内两台机器都崩溃了，所以Core Duo系统并不比286好到哪里去
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||

我可没说C++在这个地方有优势,而是您说delphi有优势,而我反驳了而已,并没有C++在这个地方更好的意思.


你当然没有说C++有优势了，而且还没明白我的意思，我说的就是你的反驳方法无效。


我可不是说要独裁,delphi的RAD是VC不及的地方,但要说写系统或底层程序,C/C++更适合


这是您第一次提“系统或底层程序”。


如果内存池无法分配,资源句柄无法分配,我想后面会有一大片代码无法继续运行了.


请你仔细想想，程序的逻辑并没有处于“没有解决方案”的地步；
真正“没有解决方案”的，是直接访问非法地址，无效指针这些情况；
这就是为什么Windows只有在这些情况才抛出异常，其他的统统都可以选用返回值。
这个道理换成*nix也是相同的，只有可以数得出来的几个Signal，其他的都是返回值。


那么希望到开放接口时,不要像前面说的那样"CAS对于其它语言的兼容性并没有作太多妥协。"


请不要偷换概念：“不妥协”绝对不是“独裁”。

退一万步讲，我并没有强迫别人使用啊。

况且，不“妥协”并不是“无法使用”，聪明的程序员总是会找到一些精练高效的解决方案。
提示：Borland / CodeGear并不是没有C++的产品。

当然，对于M$我只有不好意思地说"Suck It"了。
M$不是一贯的以自己为标准，然后希望别人"妥协"吗......





---
另外，“独裁者”是怎么出现的？

纵观历史，“独裁者”都是因为其他人一步步地“妥协”，“独裁者”才得寸进尺、得尺进丈，成为真正的独裁者的。
所谓独裁，也就是将其他人的“妥协”认为是理所当然的。

因此每个实体，不管是个人、公司还是国家，都需要坚持好自己的原则，关键时刻决不妥协，才能避免重蹈前人的血泪悲剧。
最后编辑Prz 最后编辑于 2007-06-13 01:15:02
飛べない翼に、意味はあるんでしょうか？
TOP
dwing
头像

  • - 千夏轮回的终点 -
  • 来自：
  • 性别：土豆
  • 生日：
  • 注册： 2007-03-08
  • 精华：0
  • 学分：0 个
  • 好人卡：30 张
  • 好感度：0
  • [帝都]
2007-06-13 09:13 |只看该用户 25#
t T

回复: [M] Prelude to K.O. (4.5) + 12楼(4.75)

很遗憾的发现，你根本没有仔细阅读你自己在前面贴出来的那边CSDN的Blog。
构造异常的时候自动释放对象是Delphi的基本功能，不需要外加"智能"。

自动释放对象只是针对成员变量在析构函数中释放吧.

你当然没有说C++有优势了，而且还没明白我的意思，我说的就是你的反驳方法无效。

不要因为你举了一个无法说明问题的例子就说我的反驳无效.

请不要偷换概念：“不妥协”绝对不是“独裁”。
当然，对于M$我只有不好意思地说"Suck It"了。
M$不是一贯的以自己为标准，然后希望别人"妥协"吗......

我可没说"不妥协"是"独裁",不要妄加推断.
没有正当理由排斥MS,是无法让人信服的.
不要总是提到"独裁者",你又不想针对我,那你想说明什么?
我不清楚你"不妥协"的是什么?
还有,不要总拿delphi和C++比较,二者不是同一层次的东西,C++不是MS独占的.
不要把话题转得太远,本楼辩论焦点是为什么delphi/object pascal的接口不去支持C++.是技术原因还是个人原因.
最后编辑dwing 最后编辑于 2007-06-13 09:18:42
TOP
Prz
头像

千砂与美纱的神隐

  • - 根性组 -
  • 来自：国立万年小学校
  • 人家是女孩子的说
  • 生日：2003-06-01
  • 注册： 2002-09-18
  • 精华：15
  • 学分：0 个
  • 好人卡：40 张
  • 好感度：550
  • [爸爸国]
2007-06-13 17:29 |只看楼主 26#
t T

回复: [M] Prelude to K.O. (4.5) + 12楼(4.75)

没有正当理由排斥MS,是无法让人信服的.


哈哈，我什么时候排斥了？您如果不是逻辑混乱，就是偷换概念的高手！
似乎从头到尾只有你一个人在明指暗点的排斥Delphi / Pascal。

说深奥了，大家不一定都看得明白，就用一个非常直接的比喻：
0. 我想要写一段相声，用四川方言；
1. 说普通话的dwing同学于是说："你要想有前途的话，就必须要用普通话"。
2. 然后我反驳说，请不要歧视四川方言，语言是丰富多彩的，要学会欣赏各种不同语言的美。
3. dwing同学不买账。
4. 于是，我举出例子表明四川方言有很多用法可以表达出普通话无法表达的东西。
5. dwing同学反驳说，不论四川方言还是普通话，都有表达不出来的东西，因此两个都差不多。
(大概想表明，普通话对方言的优势就一定很优，劣势就一定可以忽略不计)
6. 我说，你这样说不对，很简单：世界上没有事物是完美的，就凭这一点我还可以把所有的东西都打成一片，那任何辩论都没有意义了。
7. dwing同学说，那还是不行，只要你说四川方言的优点就是排斥普通话！
8. 我说什么呢？无言... (不论用四川话还是普通话都无法形容....)

我不清楚你"不妥协"的是什么?


赫赫，都说了这么久了，您还不明白最开始您和我讨论的是什么？

不妥协，表示的是我会按照自己的意愿编写自己的程序。
不会为了某个人偏激的“前途论”而做出计划外的改变。


还有,不要总拿delphi和C++比较,二者不是同一层次的东西

只要不点破，这句话我们可以在保持自己的理解的基础上达成一致。
（点破了不好，光制造混乱，没有任何意义）


本楼辩论焦点是为什么delphi/object pascal的接口不去支持C++.是技术原因还是个人原因.


赫赫，请不要将自己的理解任意的加在别人的观点上。
就像前面我已经再三暗示过的，您的所谓“不支持”的理解是狭隘的。
您希望的支持，大概就是一定用M$扩展标准的VC写出原生代码，而且编程风格都要符合你的要求，你抓过来就用；
如果需要做一点点其他的工作，比如对象包裹，或者异常过滤，那就是"不支持"。

当然，这我不是做不到，如果你给我开工资单的话。

前面我已经提示了：对于一个精明的程序员来说，"不支持"的程序根本就是不存在的。
就拿CAS来说，使用对象包裹+异常过滤，M$C++应该就可以使用了；
如果觉得麻烦，还可以使用Borland / CodeGear C++，对于Delphi的兼容性要良好的多，很多工作ECO都做好了。

所以，从某种角度上来说，“不支持”的发生得确是“技术原因”，不过是使用方的。:P
飛べない翼に、意味はあるんでしょうか？
TOP
dwing
头像

  • - 千夏轮回的终点 -
  • 来自：
  • 性别：土豆
  • 生日：
  • 注册： 2007-03-08
  • 精华：0
  • 学分：0 个
  • 好人卡：30 张
  • 好感度：0
  • [帝都]
2007-06-13 18:03 |只看该用户 27#
t T

回复：[M] Prelude to K.O. (4.5) + 12楼(4.75)

Prz以上的言论都是为只支持delphi/object pascal找借口.
你说了这么多,明指暗点的排斥C++谁都能看得出来.
我不排斥你用什么语言开发,
但写开发包的一个目标尽可能对其他语言的支持(就像与外地人不要用方言交流一样).
如果仅考虑delphi,那我也没有办法.
这种做法永远不能像COM一样大度.
看看以后"方言"的CAS会有什么作为吧...

PS:不要总用"偷换概念","请不要将自己的理解任意的加在别人的观点上"这些话语来逃避自己失误.
TOP
cheong00
头像

理昌

  • - 根性组 -
  • 来自：
  • 性别：男
  • 生日：1980-08-15
  • 注册： 2005-02-18
  • 精华：0
  • 学分：0 个
  • 好人卡：30 张
  • 好感度：14
  • 香港
2007-06-14 00:56 |只看该用户 28#
t T

回复: [M] Prelude to K.O. (4.5) + 12楼(4.75)

亂入一下...

其實 Exception 的處理實在是很麻煩的. 即使用 try...catch... 結構也還是會有無法被處理的情形. (如 StackOverflow 做成的 stack corruption, 還有 OutOfMemory 的情況)

Constructor / Destructor 的 Exception 也不一定是可以避免的 尤其是在 MultiThread 的環境下, 當別人的 thread 要對你的thread進行Thread Abort 時, 也不見得會看你有沒有在new / delete object.

.NET framework v2.0 特別為這問題設立 System.Runtime.ConstrainedExexution namespace, 在 technet 有詳細介紹. 有興趣的可以一看.

原帖由 dwing 于 2007-6-13 18:03:00 发表
Prz以上的言论都是为只支持delphi/object pascal找借口.
你说了这么多,明指暗点的排斥C++谁都能看得出来.
我不排斥你用什么语言开发,
但写开发包的一个目标尽可能对其他语言的支持(就像与外地人不要用方言交流一样......

btw, 我確實沒有看到他排斥C++的地方.

寫開發包也不一定會對其他語言支持. 即使一些有名的如 TWAIN (控制 scanner 的 library )基本上也只支持 C++. Delphi 用的版本也只是高手們自已寫的 wrapper, 沒有官方支持. 而支援 .NET framework 的語言(不包括 C++) 只可以自己轉, 或者花錢買其他人做好的, 或者乾脆死心只支援有支援 WIA 的 scanner 了. 這在寫 SDK 的人來說十分正常. 要知道光測試一種語言可以使用的 test case 就有很多, 即使是要拿出去賣的也不一定會花時間支援其他語言的, 何況只是一個 pet project (指只是在工餘時間, 為自己的喜好自發完成的東西)?

最後一點就是, 要開發跨語言的 SDK 的話, 除非 compiler 本身已有很好的支援, 否則要為「非慣用」的語言做相容性調整可不是一般的困難及麻煩. 不想花額外時間在那些事情也是可以理解的吧?

這次 SDK 的發佈可見是有點公諸同好的性質, 我想要求在派禮物的同時還把禮物送到你家大門是否有點苛求呢?
最后编辑cheong00 最后编辑于 2007-06-14 01:32:37
TOP
dwing
头像

  • - 千夏轮回的终点 -
  • 来自：
  • 性别：土豆
  • 生日：
  • 注册： 2007-03-08
  • 精华：0
  • 学分：0 个
  • 好人卡：30 张
  • 好感度：0
  • [帝都]
2007-06-14 09:02 |只看该用户 29#
t T

回复：[M] Prelude to K.O. (4.5) + 12楼(4.75)

楼上所说有理,但delphi的一些高级特性,用其他语言是无法做wrapper来支持的.
我并不强求支持其他语言,我只是提个意见,我见过太多的免费C/C++开发库,
对语言的支持度都非常高,微软的DX使用COM,语言兼容程度更不必说.
为什么对其他语言支持的开发库都使用C/C++,而delphi写的库就很少支持其他语言呢.
我认为C/C++很少利用编译器内在的东西,连字符串类型都需要自己定义类.
这样接口所关联的数据类型都是很基本的东西,其他语言都能很好地兼容.
而delphi等一些高级语言太依靠编译器本身提供的东西了(这些东西一般是没有源码参考的,
只有逆向去分析它们的结构),不能保证其他语言都会提供(可能连wrapper都无法写出),
否则就要在接口上做麻烦的转换,太习惯于以至于产生依赖感的人就不愿考虑这个问题.
而习惯于用C/C++的人由于很少利用这些东西,所以遇到使用黑箱操作的高级特性的接口,就会有排斥感.
最后编辑dwing 最后编辑于 2007-06-14 09:06:37
TOP
Prz
头像

千砂与美纱的神隐

  • - 根性组 -
  • 来自：国立万年小学校
  • 人家是女孩子的说
  • 生日：2003-06-01
  • 注册： 2002-09-18
  • 精华：15
  • 学分：0 个
  • 好人卡：40 张
  • 好感度：550
  • [爸爸国]
2007-06-14 10:14 |只看楼主 30#
t T

回复: [M] Prelude to K.O. (4.5) + 12楼(4.75)

Prz以上的言论都是为只支持delphi/object pascal找借口


因为你自己不想做自己应该做的事情而怪别人，我也没办法。

话又说回来，我看不出来“用Delphi写程序”为什么就一定有“兼容”C++的义务？
你的回帖里面搞得好像如果不嘴对嘴(就像大鸟喂小鸟)的支持C++就是一种罪过似的，不是“偷换概念”“变相攻击”是什么呢？


而delphi等一些高级语言太依靠编译器本身提供的东西了(这些东西一般是没有源码参考的,只有逆向去分析它们的结构),


信口开河的习惯又来了。
Delphi中所有的对象和语言元素都提供了原代码，就算是编译器内部的对象比如字符串类型，都提供了"伪代码"演示结构。

通过自己进行对象包装，完全可以实现Delphi到C++的兼容，而且也不是什么"黑箱"——因为包裹代码都是你自己写的。(反过来要我提供兼容性才是真正的黑箱)
如果你因要说"不兼容"，那么一则可能是出于懒惰不想写代码，二则大约是出于自大，对其他语言不屑一顾，自然也就不明白怎么写。
所以说，您说的"不兼容"，得确是属于"技术原因"+"个人原因"。
最后编辑Prz 最后编辑于 2007-06-14 10:15:38
飛べない翼に、意味はあるんでしょうか？
TOP
返回列表 1234
上一主题 | 下一主题