这 Go 的边界检查

们只有当数组的长度和容量相等时， :index 成立，才能一定能推出 index: 也成立，这样的话，只要做一次检查即可

一旦数组的长度和容量不相等，那么 index 在编译器看来是有可能大于数组长度的，甚至大于数组的容量。

我们假设 index 取得的随机数为 4，那么它大于数组长度，此时 s[:index] 虽然可以成功，但是 s[index:] 是要失败的，因此第二次边界的检查是有必要的。

你可能会说， index 不是最大值为 3 吗?怎么可能是 4呢?

要知道编译器在编译的时候，并不知道 index 的最大值是 3 呢。

小结一下

当数组的长度和容量相等时，s[:index] 成立能够保证 s[index:] 也成立，因为只要检查一次即可

当数组的长度和容量不等时，s[:index] 成立不能保证 s[index:] 也成立，因为要检查两次才可以

3.4 案例四

有了上面的铺垫，再来看下面这个示例，由于数组是调用者传入的参数，所以编译器的编译的时候无法得知数组的长度和容量是否相等，因此只能保险一点，两个都检查。

. 主动消除边界检查

虽然编译器已经非常努力去消除一些应该消除的边界检查，但难免会有一些遗漏。

这就需要"警民合作"，对于那些编译器还未考虑到的场景，但开发者又极力追求程序的运行效率的，可以使用一些小技巧给出一些暗示，告诉编译器哪些地方可以不用做边界检查。

比如下面这个示例，从代码的逻辑上来说，是完全没有必要做边界检查的，但是编译器并没有那么智能，实际上每个for循环，它都要做一次边界的检查，非常的浪费性能。文上面列出的例子并没有涵盖标准编译器支持的所有边界检查消除的情形。本文列出的仅仅是一些常见的情形。

尽管标准编译器中的边界检查消除特性依然不是100%完美，但是对很多常见的情形，它确实很有效。自从标准编译器支持此特性以来，在每个版本更新中，此特性都在不断地改进增强。无需质疑，在以后的版本中，标准编译器会更加得智能，以至于上面第5个例子中提供给编译器的暗示有可能将变得不再必要。谢谢Go语言开发团队出色的工作!

（编辑：沧州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!