将基本（非指针）参数设置为常量是否有意义？

Question

最近我和另一位 C++ 开发人员就 const 的如下使用进行了交流：

void Foo(const int bar);

他觉得这样使用 const 是一个很好的做法。

我认为它对函数的调用者没有任何作用（因为将传递参数的副本，所以在覆盖方面没有额外的安全保证）。此外，这样做可以防止 Foo 的实现者修改其参数的私有副本。因此，它既规定又宣传了实施细节。

这不是世界末日，但肯定不是值得推荐的良好实践。

我很好奇其他人对这个问题的看法。

编辑：

好的，我没有意识到参数的常量性并没有影响函数的签名。因此，可以在实现 (.cpp) 中将参数标记为 const，而不是在标头 (.h) 中 - 并且编译器对此很满意。既然如此，我想局部变量 const 的策略应该是相同的。

有人可能会说，在头文件和源文件中具有不同的外观签名会让其他人感到困惑（就像它会让我感到困惑一样）。虽然我尝试在我写的任何内容中遵循最小惊讶原则，但我想这是合理的预期开发人员承认这是合法且有用的。

Answer 1

还记得 if(NULL == p) 模式吗？

有很多人会告诉“你必须这样编写代码”：

if(NULL == myPointer) { /* etc. */ }

而不是

if(myPointer == NULL) { /* etc. */ }

理由是第一个版本将保护编码器免受代码拼写错误的影响，例如将“==”替换为“=”（因为这是禁止的将一个值赋给一个常数值）。

下面可以被认为是这个有限的 if(NULL == p) 模式的扩展：

为什么 const 参数对编码器有用

无论什么类型，“const”都是一个限定符我补充说，“我不希望该值发生变化，所以如果我撒谎，请向我发送编译器错误消息”。

例如，这种代码会显示编译器何时可以帮助我：

void bar_const(const int & param) ;
void bar_non_const(int & param) ;

void foo(const int param)
{
   const int value = getValue() ;

   if(param == 25) { /* Etc. */ } // Ok
   if(value == 25) { /* Etc. */ } // Ok

   if(param = 25) { /* Etc. */ } // COMPILE ERROR
   if(value = 25) { /* Etc. */ } // COMPILE ERROR

   bar_const(param) ;  // Ok
   bar_const(value) ;  // Ok

   bar_non_const(param) ;  // COMPILE ERROR
   bar_non_const(value) ;  // COMPILE ERROR

   // Here, I expect to continue to use "param" and "value" with
   // their original values, so having some random code or error
   // change it would be a runtime error...
}

在这些情况下，可能因代码拼写错误或函数调用中的某些错误而发生，编译器将捕获它，这是一件好事< /i>.

为什么它对用户来说不重要

碰巧：

void foo(const int param) ;

和：

void foo(int param) ;

具有相同的签名。

这是一件好事，因为，如果函数实现者决定函数内的参数被视为 const，则用户不应该也不需要知道它。

这解释了为什么我对用户的函数声明省略了 const:

void bar(int param, const char * p) ;

以使声明尽可能清晰，而我的函数定义则尽可能多地添加它：

void bar(const int param, const char * const p)
{
   // etc.
}

使我的代码尽可能健壮。

但为什么在现实世界中，它可能打破了

我被我的模式所困扰的情况。

在一些保持匿名的损坏编译器上（其名称以“Sol”开头并以“aris CC”结尾），上面的两个签名可以被认为是不同的（取决于在上下文中），因此，运行时链接可能会失败。

由于该项目也是在 Unix 平台（Linux 和 Solaris）上编译的，因此在这些平台上，未定义的符号在执行时需要解析，这会在进程执行过程中引发运行时错误。

因此，因为我必须支持上述编译器，所以我最终用 consted 原型污染了我的标头。

但我仍然认为这种在函数定义中添加 const 的模式是一个很好的模式。

注意：Sun Microsystems 甚至有胆量用“无论如何它都是邪恶的模式，所以你不应该使用它”声明来隐藏其损坏的损坏。请参阅 http://docs。 oracle.com/cd/E19059-01/stud.9/817-6698/Ch1.Intro.html#71468

最后一点

必须指出的是，Bjarne Stroustrup 似乎一直反对考虑 void foo(int) 与 void foo(const int) 具有相同的原型：

不过，在我看来，并非所有接受的功能都是改进。例如，[...] void f(T) 和 void f(const T) 表示相同函数的规则（由 Tom 提出）
Plum 出于 C 兼容性原因）[拥有]“在我的尸体上”被投票为 C++ 的可疑区别。

资料来源：Bjarne Stroustrup
在现实世界中并为现实世界发展一种语言：C++ 1991-2006，5。语言特征：1991-1998，第 21 页。
http://www.stroustrup.com/hopl-almost-final.pdf

考虑到赫伯·萨特提出了相反的观点，这很有趣：

指南：避免在函数声明中使用 const 按值传递参数。如果不修改参数，仍将参数设置为 const 在同一个函数的定义中。

资料来源：赫伯·萨特
卓越的 C++，第 43 项：常量正确性，第 177-178 页。

Answer 2

这个问题已经讨论过很多次了，大多数人最终都不得不同意不同意。就我个人而言，我同意这是毫无意义的，并且标准隐含地同意 - 顶级 const （或易失性）限定符不构成函数签名的一部分。在我看来，想要使用这样的顶级限定符（强烈地）表明该人可能会口头上支持将接口与实现分开，但实际上并不理解其中的区别。

另一个小细节：它确实适用于引用，就像指针一样......

Answer 3

它使编译器完成捕获错误的部分工作。如果您不应该修改它，请将其设置为常量，如果您忘记了，编译器会对您大喊大叫。

Answer 4

如果 bar 被标记为 const ，如上所述，那么阅读代码的人知道传入的内容，就始终确切知道什么bar 包含。无需事先查看任何代码来查看 bar 在此过程中是否发生更改。这使得对代码的推理变得更简单，从而减少了错误潜入的机会。

我自己投票“良好实践”。当然，这些天我也几乎转换为函数式语言，所以......

---

解决下面的评论，考虑这个源文件：

// test.c++

bool testSomething()
{
    return true;
}

int test1(int a)
{
    if (testSomething())
    {
        a += 5;
    }
    return a;
}

int test2(const int a)
{
    if (testSomething())
    {
        a += 5;
    }
    return a;
}

在 test1 中，我无法知道值是什么被返回将不会读取（可能相当大和/或复杂的）函数主体并且而不会追踪（可能遥远的、相当大的、复杂的和/或源不可用) 函数 testSomething 的主体。此外，a 的更改可能是可怕的拼写错误的结果。

test2 中的相同拼写错误会在编译时导致这种情况：

$ g++ test.c++
test.c++: In function ‘int test2(int)’:
test.c++:21: error: assignment of read-only parameter ‘a’

如果它是一个拼写错误，我会发现它。如果不是拼写错误，以下是更好的编码选择，IMO：

int test2(const int a)
{
    int b = a;
    if (testSomething())
    {
        b += 5;
    }
    return b;
}

即使是半生不熟的优化器也会生成与 test1 情况相同的代码，但您表示要关心和必须予以注意。

为可读性编写代码涉及的不仅仅是选择时髦的名称。

Answer 5

我是一个const迷，所以我个人很喜欢它。大多数情况下，向代码读者指出传入的变量不会被修改是有用的；就像我尝试将函数体内创建的所有其他变量标记为 const（如果未修改）一样。

我也倾向于保持函数签名匹配，即使它没有太多意义。部分是因为它不会造成任何损害，部分是因为如果签名不同，Doxygen 过去会感到有点困惑。