c/c++开发分享在什么阶段if / else变得比switch案更好? 可以?

根据我的阅读,我可以总结一下,

考虑一下我有300多个开关盒的情况。 我知道这个场景中的if/elseif会很乱。

但我想知道switch盒在这样的场景中会如何表现?

我主要对C / C ++的具体细节感兴趣

    编译器可能会决定使用跳转表,并在300+的情况下进行大幅改进。

    编译器使用决策树等各种技术对分支进行优化。

    编译器理解代码越容易越好。 并且switch语句对于编译器来说也更具可读性。

    从编译器的角度考虑其他问题。 它看起来像一个箭头:

      - if - else - else - else - else 

    您需要评估每个先前的if,以便找到正确的else。

    但是,Switch看起来更像一个块:

      - case - case - case - case 

    因此,编译器有时可以确定直接去哪里。

    对于你的子弹问题:

    大多数低端处理器(主要用于嵌入式系统)编译器的编译器并不总是为switch case生成跳转表。

    如果案例变量是顺序的(例如1,2,3,4 ….)那么编译器首选跳转表实现开关案例,但对于案例变量的随机序列(例如12,344,565,1,5 … )编译器生成与if-else代码生成的代码相同的代码。

    有时候,由于这个开发人员在将随机案例变量添加到已经OK代码中时会遇到麻烦,可能会改变代码段的整个实现,这可能导致代码执行时序和代码大小的重大变化。 这些是嵌入式开发人员最关心的问题。

    如果您没有多少选择,使用深度决策树或需要使用非特定决策,那么if else优于switch案例,

    即。 很容易实现一个if语句来检查int是否大于0,这更难以构建到switch语句中。 这是使用if语句最好实现的逻辑类型。

    如果您有一个扁平的,非常宽泛但具体的条件依赖决策表,那么切换情况会更好。 例如,如果值为1,2,3,4 …等到10时,您希望发生特定事情,使用开关案例将更容易和更准确。

    最后,现代编译器会将其更改为最有效的计算方式,但是如何构建它会影响function,并且一旦构建就会影响可支持性。

    从将开关与if..then..else构造进行比较的问题来看,〜我假设你只是需要进行单一测试并且结果取决于答案的情况(例如,如果x == ??然后 …)。 在这种情况下使用开关总是更好,因为:a)你不能在测试链的一部分引入错误的条件。 b)测试只进行一次。

      以上就是c/c++开发分享在什么阶段if / else变得比switch案更好? 可以?相关内容,想了解更多C/C++开发(异常处理)及C/C++游戏开发关注(猴子技术宅)。

      本文来自网络收集,不代表猴子技术宅立场,如涉及侵权请点击右边联系管理员删除。

      如若转载,请注明出处:https://www.ssfiction.com/c-cyuyankaifa/546028.html

      发表评论

      电子邮件地址不会被公开。 必填项已用*标注