对函数参数使用“const”

当参数按值传递时， const 毫无意义，因为您不会修改调用者的对象。

错误的。

这是关于自我记录你的代码和你的假设。

如果您的代码有很多人在处理它并且您的功能不平凡，那么您应该标记 const 任何和所有可以做的事情。在编写工业级代码时，您应该始终假设您的同事是精神病患者，他们试图以任何方式得到您（尤其是因为将来通常是您自己）。

此外，正如前面有人提到的，它可能会帮助编译器优化一些东西（尽管它是一个很长的镜头）。

原因是参数的 const 仅在函数内本地应用，因为它正在处理数据的副本。这意味着函数签名无论如何都是一样的。不过，经常这样做可能是不好的风格。

我个人倾向于不使用 const，除了引用和指针参数。对于复制的对象，这并不重要，尽管它可以更安全，因为它在函数内发出意图信号。这真的是一个判断电话。我确实倾向于使用 const_iterator 虽然在循环某些东西时我不打算修改它，所以我猜每个人都有自己的想法，只要严格维护引用类型的 const 正确性。

有时（太频繁了！）我必须解开别人的 C++ 代码。而且我们都知道，根据定义，其他人的 C++ 代码几乎是一团糟 :) 所以我破译本地数据流的第一件事就是将 const 放入每个变量定义中，直到编译器开始咆哮。这也意味着 const 限定值参数，因为它们只是由调用者初始化的花哨的局部变量。

啊，我希望变量默认为 const 而非 const 变量需要可变 :)

以下两行在功能上是等效的：

int foo (int a);
int foo (const int a);

显然，如果 foo 以第二种方式定义，您将无法修改 foo 的主体中的 a，但与外部没有区别。

const 真正派上用场的是引用或指针参数：

int foo (const BigStruct &a);
int foo (const BigStruct *a);

这说明 foo 可以采用一个大参数，也许是一个千兆字节大小的数据结构，而无需复制它。此外，它对调用者说：“Foo 不会* 更改该参数的内容。”传递 const 引用还允许编译器做出某些性能决策。

*：除非它抛弃了 const-ness，但那是另一篇文章。

从 API 的角度来看，多余的 const 是不好的：

在代码中为按值传递的内部类型参数添加多余的 const 会使您的 API 混乱，同时对调用者或 API 用户没有任何有意义的承诺（它只会妨碍实现）。

API 中不需要的太多“const”就像“哭泣的狼”，最终人们会开始忽略“const”，因为它无处不在，而且大多数时候没有任何意义。

API 中额外 const 的“reductio ad absurdum”参数对于前两点是好的，如果更多的 const 参数是好的，那么每个可以有 const 的参数都应该有 const。事实上，如果它真的那么好，你会希望 const 成为参数的默认值，并且只有在你想更改参数时才有像“mutable”这样的关键字。

因此，让我们尽可能地尝试放入 const ：

void mungerum(char * buffer, const char * mask, int count);

void mungerum(char * const buffer, const char * const mask, const int count);

考虑上面的代码行。不仅声明更混乱、更长、更难阅读，而且 API 用户可以安全地忽略四个“const”关键字中的三个。然而，'const' 的额外使用使得第二行可能很危险！

为什么？

对第一个参数 char * const buffer 的快速误读可能会让您认为它不会修改传入的数据缓冲区中的内存——然而，事实并非如此！ 在快速扫描或误读时，多余的 'const' 可能会导致对 API 的危险和错误假设。

从代码实现的角度来看，多余的 const 也是不好的：

#if FLEXIBLE_IMPLEMENTATION
       #define SUPERFLUOUS_CONST
#else
       #define SUPERFLUOUS_CONST             const
#endif

void bytecopy(char * SUPERFLUOUS_CONST dest,
   const char *source, SUPERFLUOUS_CONST int count);

如果 FLEXIBLE_IMPLEMENTATION 不为真，那么 API “承诺”不会以下面的第一种方式实现该功能。

void bytecopy(char * SUPERFLUOUS_CONST dest,
   const char *source, SUPERFLUOUS_CONST int count)
{
       // Will break if !FLEXIBLE_IMPLEMENTATION
       while(count--)
       {
              *dest++=*source++;
       }
}

void bytecopy(char * SUPERFLUOUS_CONST dest,
   const char *source, SUPERFLUOUS_CONST int count)
{
       for(int i=0;i<count;i++)
       {
              dest[i]=source[i];
       }
}

这是一个非常愚蠢的承诺。为什么你要做出一个对你的调用者没有任何好处并且只会限制你的实现的承诺？

尽管这两者都是相同功能的完全有效的实现，但您所做的只是将一只手不必要地绑在背后。

此外，这是一个很容易（并且在法律上被规避）的非常肤浅的承诺。

inline void bytecopyWrapped(char * dest,
   const char *source, int count)
{
       while(count--)
       {
              *dest++=*source++;
       }
}
void bytecopy(char * SUPERFLUOUS_CONST dest,
   const char *source,SUPERFLUOUS_CONST int count)
{
    bytecopyWrapped(dest, source, count);
}

看，尽管我承诺不这样做，但我还是以这种方式实现了它——只是使用了一个包装函数。这就像当坏人在电影中承诺不杀人并命令他的心腹杀死他们时一样。

那些多余的 const 只值一个电影坏蛋的承诺。

但是说谎的能力变得更糟了：

我已经了解到，您可以通过使用虚假 const 使标头（声明）和代码（定义）中的 const 不匹配。 const-happy 的拥护者声称这是一件好事，因为它允许您仅将 const 放在定义中。

// Example of const only in definition, not declaration
struct foo { void test(int *pi); };
void foo::test(int * const pi) { }

但是，反之亦然……您只能在声明中放置虚假的 const 并在定义中忽略它。这只会使 API 中多余的 const 变得更加可怕，而且是可怕的谎言——请看这个例子：

struct foo
{
    void test(int * const pi);
};

void foo::test(int *pi) // Look, the const in the definition is so superfluous I can ignore it here
{
    pi++;  // I promised in my definition I wouldn't modify this
}

所有多余的 const 实际上所做的只是通过强制实现者在想要更改变量或通过非 const 引用传递变量时使用另一个本地副本或包装函数来降低实现者的代码的可读性。

看看这个例子。哪个更具可读性？很明显，第二个函数中额外变量的唯一原因是因为某些 API 设计人员投入了多余的 const 吗？

struct llist
{
    llist * next;
};

void walkllist(llist *plist)
{
    llist *pnext;
    while(plist)
    {
        pnext=plist->next;
        walk(plist);
        plist=pnext;    // This line wouldn't compile if plist was const
    }
}

void walkllist(llist * SUPERFLUOUS_CONST plist)
{
    llist * pnotconst=plist;
    llist *pnext;
    while(pnotconst)
    {
        pnext=pnotconst->next;
        walk(pnotconst);
        pnotconst=pnext;
    }
}

希望我们在这里学到了一些东西。多余的 const 是一个 API 杂乱无章的讨厌东西，一个烦人的唠叨，一个肤浅而毫无意义的承诺，一个不必要的障碍，并且偶尔会导致非常危险的错误。

const 应该是 C++ 中的默认值。像这样 ：

int i = 5 ; // i is a constant

var int i = 5 ; // i is a real variable

当我以编写 C++ 为生时，我尽我所能。使用 const 是帮助编译器帮助您的好方法。例如，对您的方法返回值进行 const-ing 可以使您免于打字错误，例如：

foo() = 42

当你的意思是：

foo() == 42

如果 foo() 被定义为返回一个非常量引用：

int& foo() { /* ... */ }

编译器很乐意让你为函数调用返回的匿名临时赋值。使其成为常量：

const int& foo() { /* ... */ }

消除了这种可能性。

在 comp.lang.c++.moderated here 上的旧“本周大师”文章中对此主题进行了很好的讨论。

Herb Sutter 的网站 here 上提供了相应的 GOTW 文章。

1. 基于我的评估的最佳答案：

根据我的评估，The answer by @Adisak 是这里的最佳答案。请注意，这个答案在一定程度上是最好的，因为它也是最有真实代码示例支持的，除了使用声音和良好 -深思熟虑的逻辑。

2.我自己的话（同意最佳答案）：

对于按值传递，添加 const 没有任何好处。它所做的只是：限制实现者每次想要更改源代码中的输入参数时都必须制作一个副本（这种更改无论如何都不会产生副作用，因为传入的已经是一个副本，因为它是传递的 -价值）。并且经常使用更改按值传递的输入参数来实现该功能，因此在任何地方添加 const 都会阻碍这一点。并且添加 const 会不必要地使代码到处都是 const，从而将注意力从拥有安全代码真正必要的 const 上转移开。然而，在处理指针或引用时，const 在需要时非常重要，并且必须使用，因为它可以防止函数外部持续更改带来的不良副作用，因此当参数是输入时，每个指针或引用都必须使用 const只是，不是输出。仅在通过引用或指针传递的参数上使用 const 有一个额外的好处，那就是让哪些参数是指针或引用非常明显。伸出手说“当心！任何旁边带有 const 的参数都是引用或指针！”是另一回事。我上面所描述的经常是在我工作过的专业软件组织中达成的共识，并且被认为是最佳实践。有时，规则甚至是严格的：“永远不要对按值传递的参数使用 const，但如果它们只是输入，则始终对通过引用或指针传递的参数使用它。”

3.谷歌的话（同意我的最佳答案）：

（来自“Google C++ Style Guide”）

对于按值传递的函数参数，const 对调用者没有影响，因此不建议在函数声明中使用。参见 TotW #109。

既不鼓励也不鼓励对局部变量使用 const。

来源：Google C++ 风格指南的“使用 const”部分：https://google.github.io/styleguide/cppguide.html#Use_of_const。这实际上是一个非常有价值的部分，因此请阅读整个部分。

请注意，“TotW #109”代表 "Tip of the Week #109: Meaningful const in Function Declarations"，也是一种有用的读法。它提供了更多信息，但对做什么的规定更少，并且基于上下文在上面引用的 const 上的 Google C++ 样式指南规则，但由于它提供的清晰性，上面引用的 const 规则已添加到 Google C++ 样式指南中。

另请注意，即使我在此处引用 Google C++ 样式指南来捍卫我的立场，但这并不意味着我始终遵循指南或始终建议遵循指南。他们推荐的一些东西很奇怪，例如 their kDaysInAWeek-style naming convention for "Constant Names"。 然而，当世界上最成功和最有影响力的技术和软件公司之一使用与我和 @Adisak 等其他人一样的理由来支持我们在这个问题上的观点时，指出它仍然是有用和相关的。< /em>

void f(char * const c_string);   // Bad: const is top level. [This makes the _pointer itself_, NOT what it points to, const]
void f(const char * c_string);   // Good: const is not top level. [This makes what is being _pointed to_ const]

void f(const std::string);   // Bad: const is top level.
void f(const std::string&);  // Good: const is not top level.

void f(char * const c_string);   // Bad: const is top level. [This makes the _pointer itself_, NOT what it points to, const]
void f(const char * c_string);   // Good: const is not top level. [This makes what is being _pointed to_ const]

// BAD--do not do this:
const int foo();
const Clazz foo();
Clazz *const foo();

// OK--up to the implementer:
const int* foo();
const int& foo();
const Clazz* foo();