- 主题:c++太垃圾
静态边界检查不可能完备，且检测能力与编译器实现复杂度有关；动态边界检查有代价。语言不方便规定一个不确定的静态检查规则，只能规定对数组下标是不是动态检查。这个不难理解。
至于不做有代价的动态检查是不是合口味就另说。
严格说数组越界访问是UB，所以至少在语言层面并不完全是为了故意留一些特殊技巧的口子。
【 在 mrunmatched 的大作中提到: 】
: 明明编译都检查出数组越界了，愣是只报warning，还允许编译通过，是怎么想的？给黑客留后门？
: 不怪很多大公司呼吁用内存安全语言替换他，再不思进取，过几年就被淘汰了。
:
: ...................
--
修改:milksea FROM 124.64.17.*
FROM 124.64.17.*
未定义行为的消除并不是没有代价的，是否支付这种代价是设计语言的重要选择，无论选哪个都有站得住脚的理由。这里说的代价还不仅是性能上的，还可能就是语言能力上的。
比如硬件编程就是可能需要读写固定物理地址，这在c语言标准中也是未定义行为（c语言规定合法指针算数只能指向数组内），可在特定硬件场景下也不能不用。语言特性不符合自己应用场景也不奇怪，因为种种其他原因换不了语言也只能凑合用。
下标边界检查本身是个相对容易说清楚的事，静态检查原理上就做不到准确，动态检查会慢（极端情况可能慢千百倍）。数值计算领域要求不能加动态检查，至少内循环不能加，否则慢得不能接受；应用开发领域要求最好都加动态检查，这是个利弊权衡的事。
语言是不是要求静态/动态检查下标？某款编译器是不是静态/动态检查？检查结果是是否有强制效果？这几个事儿其实还是有挺多差别的。
【 在 mrunmatched 的大作中提到: 】
: 嗯，程序出现未定义行为太吓人了，这种bug神出鬼没，特别难追踪
: 【 在 HerSMTH 的大作中提到: 】
: :
: ...................
--
修改:milksea FROM 114.249.213.*
FROM 114.249.213.*
那说明你的应用场景并不完全契合c++语言。
事实上是折中的。c++可以通过使用容器，vector使用at函数来打开动态下标检查，只不过[]下标不查。
go默认就是动态检查下标，可以用编译选项关闭。此外go还有gc。go通过unsafe包支持任意指针类型转换和指针算术。
rust默认有动态下标检查，但可选用不检查下标的方法，另外迭代器访问场景不需要检查。rust无gc。
目前常用的native语言主要就这几个，选择都不太一样。
【 在 mrunmatched 的大作中提到: 】
: 是的，都是权衡取舍，我只是觉得舍弃内存安全性的代价太大了
: 【 在 milksea 的大作中提到: 】
: :
: ...................
--
FROM 114.249.213.*