为什么很少有人输入 const 正确的代码？ const 正确的代码会编译得更好/更快吗？
我非常经常将指针作为函数参数传递给只读参数（例如结构等）。例如，在这个构造函数中：
Chunk::Chunk(const string& text, COLOR * background, COLOR * foreground);
我过去更喜欢这种方式（不是const正确的），因为我认为它更容易阅读。 然而，我开始觉得这很肮脏，所以改为：
Chunk::Chunk(const string& text, const COLOR * const background,
const COLOR * const foreground);
一开始似乎很难理解，但只有在你习惯它之后才可以。我的问题是：
为什么没有人做对呢？ （我见过很少这样的代码） 编译得更好/更小/更快吗？
我确实知道有什么区别，但我真的不在乎不同的语义，因为任何阅读代码的人都可以看到参数是只读的。 （谁会更改指针地址？）
我确实知道我可以使用引用来代替，但让我们假设我不想这样做（或者我使用纯 C 语言）。
I very often pass pointer as functions args for read-only args (e.g. structs and such). For instance in this constructor:
Chunk::Chunk(const string& text, COLOR * background, COLOR * foreground);
I use to prefer this way (not const-correct) because I thought it was easier to read.
However, I am starting to feel this is dirty and do instead:
Chunk::Chunk(const string& text, const COLOR * const background,
const COLOR * const foreground);
It may seem harder to understand at first, but only until you get use to it. My question:
Why no one does it right? (I've seen little code like this)
It is better/smaller/faster compiled?
I do know what's the difference, but I really dont care the different semantic because anyone reading the code can see the args are read-only. (who would change a pointer address?)
I do know I could use references instead, but let's suppose I dont want to (or I am in plain C).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
在您列出的示例中，
您可能还应该通过 const& 传递字符串，除非您有意想要该字符串的本地副本。另外，在我看来，颜色参数应该声明为
const COLOR *而不是const COLOR * const。第二个 const 只是表明该函数不会将背景和前景指针重新指向本地的其他内存块。它不会影响调用者，因此它是一个实现细节。因此，即使实现文件明确将它们列为 const COLOR * const ，标头中的原型也应为In the example you've listed
You should probably also pass the string by
const&unless you intentionally want a local copy of that string. Also, in my opinion, the color parameter should just be declared asconst COLOR *instead ofconst COLOR * const. The secondconstjust indicates that the function will not re-point thebackgroundandforegroundpointers to some other chunks of memory locally. It does not affect the caller, and so it is an implementation detail. So, even if the implementation file explicitly lists them asconst COLOR * constthe prototype in the header should readconst 关键字是为人类设计的，它的功能非常强大。
看看这个http://www.gotw.ca/gotw/081.htm 有关 const 优化的更多信息。
const keyword is for human being and it is incredibly powerful.
Have a look at this http://www.gotw.ca/gotw/081.htm for more information on const optimization.
我相信const的主要特点是编译时正确性检查，性能的提高更像是一个令人愉快的副作用。
I believe the main feature of const is compile-time correctness checking, performance increase is more like a pleasant side effect.
const 正确性有助于编译器生成更快的代码。例如，如果您将非常量指针传递给函数，编译器可能会假设该函数已修改所引用的内存块。
编辑：（来自 Exceptional C++ Style 40 新工程难题、编程问题和解决方案）
将参数和/或返回值声明为 const 是否有助于编译器生成更优化的代码或以其他方式改进其代码生成？
简而言之，不，可能不会。
为什么或为什么不？
编译器可以在哪些方面做得更好？它可以避免参数或返回值的副本吗？不，因为参数已经通过引用传递，并且返回也已经通过引用。它可以将 x 或 someY 的副本放入只读内存中吗？不，因为 x 和 someY 都存在于其范围之外，并且来自外部世界和/或被赋予外部世界。即使 someY 在 f 本身内动态分配，它及其所有权也会交给调用者。
但是 f 体内出现的代码的可能优化又如何呢？由于 const，编译器能否以某种方式改进它为 f 主体生成的代码？
仅仅因为 x 和 someY 被声明为 const 并不一定意味着它们的位在物理上是 const。为什么不呢？因为任一类都可能具有可变成员或其道德等价物，即成员函数内的 const_casts。事实上，f 内部的代码本身可能会执行 const_casts 或 C 风格的强制转换，将 const 声明变成谎言。
在一种情况下，说 const 确实具有某种意义，那就是对象在定义它们时被设为 const。在这种情况下，编译器通常可以成功地将此类“真正 const”对象放入只读内存中，特别是如果它们是可以在编译时创建内存映像并因此可以直接存储在程序的可执行映像本身内部的 POD。此类对象通俗地称为“ROM-able”。
人们普遍认为 const 正确性有助于编译器生成更紧凑的代码。是的，const 确实是个好东西，但是本 Item 的重点是 const 主要是为人类服务的，而不是为编译器和优化器服务的。
const correctness helps compiler to generate faster code. For example, if you are passing a non-const pointer to a function compiler may assume that that function has modified the memory block that has referenced.
EDIT: (from Exceptional C++ Style 40 New Engineering Puzzles, Programming Problems, and Solutions)
Does declaring the parameter and/or the return value as const help the compiler generate more optimal code or otherwise improve its code generation?
In short, no, it probably doesn't.
Why or why not?
What could the compiler do better? Could it avoid a copy of the parameter or the return value? No, because the parameter is already passed by reference, and the return is already by reference. Could it put a copy of x or someY into read-only memory? No, because both x and someY live outside its scope and come from and/or are given to the outside world. Even if someY is dynamically allocated on the fly within f itself, it and its ownership are given up to the caller.
But what about possible optimizations of code that appears inside the body of f? Because of the const, could the compiler somehow improve the code it generates for the body of f?
Just because x and someY are declared const doesn't necessarily mean that their bits are physically const. Why not? Because either class might have mutable members or their moral equivalent, namely const_casts inside member functions. Indeed, the code inside f itself might perform const_casts or C-style casts that turn the const declarations into lies.
There is one case where saying const can really mean something, and that is when objects are made const at the point where they are defined. In that case, the compiler can often successfully put such "really const" objects into read-only memory, especially if they are PODs whose memory images can be created at compile time and therefore can be stored right inside the program's executable image itself. Such objects are colloquially called "ROM-able."
It's a common belief that const correctness helps compilers generate tighter code. Yes, const is indeed a Good Thing, but the point of this Item is that const is mainly for humans, rather than for compilers and optimizers.