c++吧 关注：650,799贴子：2,118,063
不感兴趣
开通SVIP免广告
@乐天派的小耗子:/
总算看到了。
以我来看，那篇里面基本没比战五渣高多少——没指出多少实质问题还乱抛明显不靠谱的结论——包括作者和多数评论人员。
const最大的实际问题，在于和constant没有划清界限，导致许多微妙的误导。这个在C里面更严重（C的constant在C++里面叫literal）。D&E里说过本来就是readonly。如果不算语言教育的困难，这个问题就不是什么问题，因为对于有经验的用户没什么好说的，都能忍。
话说C#看起来是好一点，但强制用户显式区分readonly和const带来的好处是否真的大于const，很难说——可能还得多折腾怎么能让实现映射到ROM上。（虽然应该比const+constexpr要优雅）。顺便，in和out参数似乎也很好很强大，不过恐怕只是实用于出参多得不像话的M$风格API上了。
影响类型的qualifier的语义更复杂，但是更强大。想想如果有必要在C#塞入个restrict，需要怎么改动语言？再如多级指针具有不同的qualifier的层次类型论限制驱动的静态检查，这是内建引用语义的语言完全做不到的。
把可读/可写之类普遍作用于对象的attribute放到继承树里是个灾难。虽说不用多继承情况可能会好点，但是明摆着copy&paste的需求增多了，或者对语言加入mixin特性的压力增大了。尤其是滥用继承是迷信class-based OO programing用户的普遍现象，至少比迷信const-correctness的用户多得多。
mutable是像个hack。不过，与其说mutable太烂，还不如说把class作为静态类型来设计的语言太烂了，导致区分const和非const的成员很麻烦——mutable几乎就是语法和语义上都最简的手法。然而看样子这里的作者和大多数评论的根本对此没概念（实现的历史经验或者性能之类），更没有考虑OOD-OOP mapping从来就不是个简单的问题：各种所谓的OO语言的设计都无法全面满足OO。那说个球。
简而言之，作为const的qualifier提供了更多东西，而且如果愿意可以有自由选择不用。至于cultrue的问题，纯属没事找事；silver bullet的问题，属于门外汉意淫。
总算看到了。
以我来看，那篇里面基本没比战五渣高多少——没指出多少实质问题还乱抛明显不靠谱的结论——包括作者和多数评论人员。
const最大的实际问题，在于和constant没有划清界限，导致许多微妙的误导。这个在C里面更严重（C的constant在C++里面叫literal）。D&E里说过本来就是readonly。如果不算语言教育的困难，这个问题就不是什么问题，因为对于有经验的用户没什么好说的，都能忍。
话说C#看起来是好一点，但强制用户显式区分readonly和const带来的好处是否真的大于const，很难说——可能还得多折腾怎么能让实现映射到ROM上。（虽然应该比const+constexpr要优雅）。顺便，in和out参数似乎也很好很强大，不过恐怕只是实用于出参多得不像话的M$风格API上了。
影响类型的qualifier的语义更复杂，但是更强大。想想如果有必要在C#塞入个restrict，需要怎么改动语言？再如多级指针具有不同的qualifier的层次类型论限制驱动的静态检查，这是内建引用语义的语言完全做不到的。
把可读/可写之类普遍作用于对象的attribute放到继承树里是个灾难。虽说不用多继承情况可能会好点，但是明摆着copy&paste的需求增多了，或者对语言加入mixin特性的压力增大了。尤其是滥用继承是迷信class-based OO programing用户的普遍现象，至少比迷信const-correctness的用户多得多。
mutable是像个hack。不过，与其说mutable太烂，还不如说把class作为静态类型来设计的语言太烂了，导致区分const和非const的成员很麻烦——mutable几乎就是语法和语义上都最简的手法。然而看样子这里的作者和大多数评论的根本对此没概念（实现的历史经验或者性能之类），更没有考虑OOD-OOP mapping从来就不是个简单的问题：各种所谓的OO语言的设计都无法全面满足OO。那说个球。
简而言之，作为const的qualifier提供了更多东西，而且如果愿意可以有自由选择不用。至于cultrue的问题，纯属没事找事；silver bullet的问题，属于门外汉意淫。
