beta 的第三篇心得:深入研究 case 语句 (50分)

B

beta

Unregistered / Unconfirmed
GUEST, unregistred user!
pyzfl:你误会了,他不是不能做到,而是不愿意,我在文章中说过了,这是为了提高效率
把字符串的分支留给程序员,让我们充分发挥想象,写出更具有针对性的代码。
 
S

SS2000

Unregistered / Unconfirmed
GUEST, unregistred user!
zjfeng,你的答案不完全,呵呵,应该是后两种一样
对于array of integer是这样了
~~~~~~~~~~~~~~~~~
不过,这个看汇编可未必能看出来,对于这三个函数
function f1(a: array of integer): integer;
var i: integer;
begin
result := 0;
for i := 0 to High(a)do
result := a + result;
end;

function f2(const a: array of integer): integer;
var i: integer;
begin
result := 0;
for i := 0 to High(a)do
result := a + result;
end;

function f3(var a: array of integer): integer;
var i: integer;
begin
result := 0;
for i := 0 to High(a)do
result := a + result;
end;
的调用
f1(a);
f2(a);
f3(a);
汇编语句如下
move eax,$0045284c
move edx,$00000fa0
call f1
move eax,$0045284c
move edx,$00000fa0
call f2
move eax,$0045284c
move edx,$00000fa0
call f3
这可看不出什么,呵呵
 
Z

zjfeng

Unregistered / Unconfirmed
GUEST, unregistred user!
看起来,好象三个都是一样的呀,不过这种问题真是吹毛求疵了
 
S

SS2000

Unregistered / Unconfirmed
GUEST, unregistred user!
我曾做一个递归函数,参数为array of string
如果加const,效率提高70%!
不加const,用了10秒,
加了const,其他不变,用3秒,怎么样?是吹毛求疵吗?
 
B

beta

Unregistered / Unconfirmed
GUEST, unregistred user!
SS2000: 呵呵,Another_eYes 刚刚已经分析过了:)
http://www.delphibbs.com/delphibbs/dispq.asp?lid=1411217
 
Z

zjfeng

Unregistered / Unconfirmed
GUEST, unregistred user!
奇怪,为什么呢,从代码上看都是一样的呀,而且编译时会对CONST进行检查,而VAR不检查,
我感觉用VAR编译速度应该快一点的呀
 
B

beta

Unregistered / Unconfirmed
GUEST, unregistred user!
zjfeng:这个东西不能靠感觉的:)
// 编译时会对CONST进行检查,而VAR不检查
你也说了,那是编译时,而我们讨论的速度是运行时:)
对于 const 和 var 都是确定的,要么不让你写,要么直接写在原处,Delphi 不干预
要是不指定,那么你可以写,不过写了过后不会影响原来的内容。不影响是什么意思?
怎么实现?那就是传说中的 Copy On Write 技术了。当你要写的时候,先复制一个副本
然后再改那个副本的内容,这样就实现了 不影响。当然,这个复制就要时间了:)
 
F

fossil

Unregistered / Unconfirmed
GUEST, unregistred user!
tseug大伯,你不服老是不行地
 
Z

zjfeng

Unregistered / Unconfirmed
GUEST, unregistred user!
对,我的意思是为什么加了CONST,居然比VAR要快
//如果加const,效率提高70%!
^^^^ 你的原话
 
B

beta

Unregistered / Unconfirmed
GUEST, unregistred user!
zjfeng:
// 你的原话
首先,那是 SS2000 写的:)
其次,他说的应该是不加 const 与加了 const 之间的区别吧:)
 
Z

zjfeng

Unregistered / Unconfirmed
GUEST, unregistred user!
我觉得也应该是这样,所以如果我吹毛求疵的话,应该是用VAR比较好,因为编译时节省了
了0.000000000000000001秒,呵呵
 
D

DoubleWood

Unregistered / Unconfirmed
GUEST, unregistred user!
哎呀怎么讨论到var什么去了?是不是有点跑题了?
我来说一下我的看法罢。
其实呢,if...else
和 case 是各有所长,不过可以肯定的是if是不会被消灭的,呵呵。
从beta改过后的测试结果我们可以看出,以5次if嵌套为分界,小于5次if 的效率高,
而超过5次之后case的优势明显。这个结果可以说相当的合理。过多的if嵌套无疑会对
程序的理解造成困难,相比之下case就清晰得多了,也更容易懂。当你在选择if 和 case
的时候不妨以5这个值作为分界,超过5层的嵌套难于阅读,尽量使用case来替换,不过我
自己实际编写程序的时候一般是以3为分界的,呵呵。
小于3的话我想没有多少人会选择case吧,在
if a=1 then
do
something
else
do
nothing;

case a of
1:do
something;
else
do
nothing;
end;
中,我一定会选择if,因为这样更清晰。
用一句话来说,简单情况的判断用if,多种情况的判断用case,这才是这两条语句的定位。
不应该机械的认为谁一定要代替谁。
另外case语句很有趣的一个地方就是else
了。从beta的分析我们可以看出来,这个else
是最先判断的!在《代码大全》中,case里的else
部分称为缺省!真是难以理解,呵呵。
因为在实际编程中,这个缺省通常是什么都不做。
还有就是在case中,虽然建议各种判断按照出现几率大小排列,但是从测试结果中也可以
看出其实影响不大,反而是if,请严格按照出现几率大小排列,这个可是非常影响效率的
哦,特别是在比较所花的时间多的时候,这个是编程的基本常识哦。
大概我的看法就是那么多了,请多指教,呵呵[:D]
 
B

beta

Unregistered / Unconfirmed
GUEST, unregistred user!
// 还有就是在case中,虽然建议各种判断按照出现几率大小排列,但是从测试结果中
// 也可以看出其实影响不大
不用看结果,看我前面的分析就知道了:)
 
J

jsxjd

Unregistered / Unconfirmed
GUEST, unregistred user!
你的心得从上一遍到这一遍好象变味了!
Case 的地址表管理,懂汇编的人应该知道。
我大概看了一下,上面的讨论似乎把 if 和 case 对立起来。这有点偏激。
这只是使用的场合不同。
在复杂的场合应该混合使用。
if 能做 case 不能做的事情,case 的效率是以内存为代价的,特别是 1,2,3,10000 的情况下。
 
B

beta

Unregistered / Unconfirmed
GUEST, unregistred user!
我想说的前面已经说过 N 次了,不想再重复了,我的手好累。
既然大家不想看,那以后我沉默就是了,反正最近忙。[:(]
 
S

SS2000

Unregistered / Unconfirmed
GUEST, unregistred user!
beta,别灰心,我支持你
 
B

beta

Unregistered / Unconfirmed
GUEST, unregistred user!
多谢 SS2000 支持!
本不想多说,但是我左思右想,有些话,不吐不快。
我承认上面我说的有些偏激,但是这不是我的本意,而是你们一贴又一贴的跟贴(不是全部)
个个都拉开一副和我辩论的架式。大家都知道辩论赛的情景,越辩越偏激,最后不管胜负,
都将远离离真理。
我知道,“真理越辩越明”,但现实情况并不总是这样。你们一人一张嘴(两只手),我
就一个人,根本没有还手的余地。
为了让“真理原辩越明”请将指向我说话的漏洞的矛头转向程序本身。
// case 的效率是以内存为代价的,特别是 1,2,3,10000 的情况下
不是的,不信你自己看。(还是忍不住了)
 
S

sky2008

Unregistered / Unconfirmed
GUEST, unregistred user!
想问一句题外话
老兄你是桂电的吗?
 
A

Another_eYes

Unregistered / Unconfirmed
GUEST, unregistred user!
哈哈哈哈哈哈哈哈哈哈
 

Similar threads

顶部