C++ 用尽可能多的 const 是好风格吗？

[iqoo]

之前写 TypeScript 时，习惯给能加 const 的变量都加上 const 。

但 C++ 里加上 const 后代码累赘了不少。

const auto v = .....

const char* const buf = ....

而且 STL 容器使用 const 修饰后，容器本身也不能修改了，而非只是变量不能改。

所以 C++ 里加上尽可能多的 const 是不是一个好风格？

[macha]

当然咯，只是很多人省事不加而已。

[wevsty]

能用 const 的地方尽量使用 const 是一个好习惯，因为能避免意外的修改。
对 STL 来说也是一样的，容器内部数据的变动很可能造成迭代器的失效或者多线程访问时出现各种各样的问题，如果确定一个地方不应该对容器内部数据进行修改，那么就应该鼓励传入 const 引用。
当然，实际操作上还是得看具体的代码需求就是了。

[inhzus]

大部分情况下、主流观点认为是是好风格（当然偶尔会看到一些也有道理的反驳观点）

[weeei]

只在关键的地方加也行，比如函数后面、局部指针变量，能够让编译器优化和避免一些低级错误。

[LuckyPocketWatch]

@inhzus
比如？

[xiangyuecn]

支持禁用 const 关键字。

[weeei]

比较操蛋的应该是 const int *p, int * const p, const int * const p; 的理解。

[Lightbright]

@weeei 什么年代了还在用传统指针 （逃

[agagega]

指针的情况，类型开头那个 const （表示指向的内容不可修改）没问题，后面的 const （表示指针本身不可修改），多数时候用不上，写起来也麻烦。因为编译器是能知道你的指针有没有被重新赋值的，大多数时候你也不需要这个约束。

定义常量的话，用 const 当然也没问题，但 constexpr 可能更接近直观理解的那种「常量」。

给方法末尾加 const 是好习惯，否则 const 对象就无法访问这些方法了。

传参数的时候，传统意义上觉得写 const T&比较好，因为这样左值右值都能传，但如果你知道这个对象不是很大，直接按值传递 T 也是好的。

C++这个 const 明显比各种对象语义的语言更好理解（先不考虑 mutable 和 const_cast 的话），一旦 const 就是整个都不能修改。

[weeei]

@Lightbright 网上很多正确使用 unique_ptr 、shared_ptr 和 weak_ptr 的文章，想用好不容易啊

[mainjzb]

是。所以 rust 默认是 const 的，除非你显示的写明 mut 才可修改。当然 C++不能这么来，历史代码不允许这样的改动。
当然 C++还有 conprex ，能 conprex 的优先 conprex 情况变的更复杂（逃
dart 稍微好点用 final 关键字等价于 const auto

[leonshaw]

应加尽加

[LuckyPocketWatch]

@Lightbright
去年接手过一段代码，是某个机床的输入设备的驱动代码，注释上的日期是 1982.06.。。。

[yalay]

flutter 就是各种 const ，当然对性能有好处的

[cnbatch]

喜欢加 const 那就加，无可厚非

虽然我个人不喜欢动不动就 const

[lovelylain]

我一般只对必要的加 const ，例如函数参数列表或返回值里的 const 指针或引用，const 常量定义，const 成员方法，const 类型转换等。基本不会对值传递的参数加 const ，也很少用 const auto 去接收函数返回值，有时候会用 const auto&接收返回值。

[nullyouraise]

我是习惯先加，报错时再去掉

[jaggerjiang]

rust 默认就是 const

[kneo]

你要是确定能行就加。
就怕你自己稀里糊涂，今天加明天发现有代码编译不过去，还不知道得改哪儿。

[tool2d]

现代编译器那么聪明（ clang ），我觉得他应该比我更懂 const ，所以我选择不加。

我以前也一直加，加到最后发现是给自己在设置编译障碍，干脆就不加了。