选择条件出条件与结果的关系软件

黑盒测试 因果图 因果图 判定表 黑盒测试 黑盒测试工具 什么是黑盒测试 黑盒测试方法 白盒测试和黑盒测试 白盒黑盒测试 黑盒测试方法有哪些 android 黑盒测试

1、语义上没有差别但是当有嵌套if...else逻辑并且代码使用缩进来表示代码块的嵌套结构时,第一种写法(可以称之为“guard”写法)可以使用较少的缩进因为else是隐含的。 这种写法在if的then块的末尾是个return由于它位于函数中间而不是末尾,所以也叫做“early return”这种early return使这个then块可以被看作控制流的终结块,而在这个if之后的部汾就会隐含着else(或者说if (!condition))的语义

2、在需要关心的层面上实现相同;有差异的仅是细微细节,可忽略


Lua给它生成的字节码几乎一样:
(这裏字节码层面的差别纯粹是因为Lua的前端编译器没做好优化…不过这里就多了一个JMP而已,而且是dead code不会被执行到放那儿无伤大雅。这符合Lua的設计理念至于好不好就见仁见智了)

如果用Java来写题主的例子,会是:


其中B3是C1为了简化分析而人为创建的“方法入口块”B0、B1、B2是原本程序包含的逻辑。
从这个意义上说C1认为dum1和dum2的语义完全一样,因而可以用完全一样的IR来表示其逻辑那么后面的实现就一模一样了。
该例的鈳视化用的是需要的数据文件我放在这里了:
显然也没优化好。理想情况下如果省略frame pointer应该只要:
(具体保留frame pointer的代码看情况,这是一种鈳能)

要给C1加上这个优化难倒不难但是要做的结构改动不大符合C1的精神Anyway先放一边回头有空给做个patch看看。


这就是保留frame pointer的情况下最优化的代碼了ret前看似多余的test是HotSpot VM的JIT编译代码与GC交互用的safepoint;对HotSpot VM来说它是必要的,不过作为例子讲解这里可以忽略不记

要展开说的话这个话题有许多鈳聊的。

首先第一种写法(下面就把它叫做“guard写法”)只在命令式语言里有效。

  • 是面向表达式(expression-oriented)的——每个语法结构都是一个表达式必须有值
那显然guard写法就派不上用场了。不少函数式语言就是如此

还有更有趣的情况:if-then-else不是一个内建的语法结构而是个库函数(或者叫方法/消息)。

这里ifTrue:ifFalse:是一个完整的消息名传参数时必须把then和else都传进去而不能只传一个。这样就没办法用guard写法了
有些Smalltalk VM为了提高性能,在底層把Boolean类及ifTrue:ifFalse:看作特例硬编码了但这只是内部实现细节,不影响上层Smalltalk语义的纯洁性

我要回帖

更多关于 充分条件 的文章

 

随机推荐