如果使用->*或。*操作符，这是必须的。

它会阻止你写出

void foo(Bar *p) { if (++p->*member > 0) { ... } }

我刚才差点就这么做了，但这可能不是你想要的结果。

我想说的是

void foo(Bar *p) { if (++(p->*member) > 0) { ... } }

如果我在Bar *和p之间放了一个const，编译器会告诉我。

1. 根据我的评估，最佳答案是:

根据我的评估，@Adisak的答案是最好的答案。请注意，这个答案在某种程度上是最好的，因为除了使用合理和深思熟虑的逻辑之外，它还使用了最完善的真实代码示例。

2. 我自己的话(同意最好的答案):

For pass-by-value there is no benefit to adding const. All it does is: limit the implementer to have to make a copy every time they want to change an input param in the source code (which change would have no side effects anyway since what's passed in is already a copy since it's pass-by-value). And frequently, changing an input param which is passed by value is used to implement the function, so adding const everywhere can hinder this. and adding const unnecessarily clutters the code with consts everywhere, drawing attention away from the consts that are truly necessary to have safe code. When dealing with pointers or references, however, const is critically important when needed, and must be used, as it prevents undesired side effects with persistent changes outside the function, and therefore every single pointer or reference must use const when the param is an input only, not an output. Using const only on parameters passed by reference or pointer has the additional benefit of making it really obvious which parameters are pointers or references. It's one more thing to stick out and say "Watch out! Any param with const next to it is a reference or pointer!". What I've described above has frequently been the consensus achieved in professional software organizations I have worked in, and has been considered best practice. Sometimes even, the rule has been strict: "don't ever use const on parameters which are passed by value, but always use it on parameters passed by reference or pointer if they are inputs only."

3.谷歌的话(同意我和最好的答案):

(摘自“谷歌c++风格指南”)

对于通过value传递的函数形参，const对调用者没有影响，因此不建议在函数声明中使用。参见tow #109。

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

来源:谷歌c++风格指南的“const的使用”部分:https://google.github.io/styleguide/cppguide.html#Use_of_const。这是一个非常有价值的部分，所以请阅读整个部分。

请注意，“tow# 109”代表“本周小贴士#109:函数声明中有意义的const”，这也是一个有用的阅读。它提供了更多的信息，对要做的事情的规定性更少，并且在谷歌c++样式指南关于上面引用的const规则之前出现，但由于它提供的清晰性，上面引用的const规则被添加到谷歌c++样式指南中。

Also note that even though I'm quoting the Google C++ Style Guide here in defense of my position, it does NOT mean I always follow the guide or always recommend following the guide. Some of the things they recommend are just plain weird, such as their kDaysInAWeek-style naming convention for "Constant Names". However, it is still nonetheless useful and relevant to point out when one of the world's most successful and influential technical and software companies uses the same justification as I and others like @Adisak do to back up our viewpoints on this matter.

4. Clang的linter, Clang -tidy，有一些选项:

答:同样值得注意的是，Clang的linter, Clang -tidy，有一个选项，可读性-avoid-const-params-in-decls，描述在这里，以支持在代码库中强制不使用const的值传递函数参数:

检查函数声明的形参是否为顶级const。

声明中的Const值不会影响函数的签名，因此它们不应该放在那里。

例子:

Void f(const字符串);//错误:const是顶级的。 Void f(const string&);//好:const不是顶级的。

为了完整和清晰，我自己再举两个例子:

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]

B.它还有这个选项:readable -const-return-type - https://clang.llvm.org/extra/clang-tidy/checks/readability-const-return-type.html

5. 我的务实的方法是如何在这个问题上给出一个风格指南:

我只需复制粘贴到我的风格指南中:

[复制/ START纸浆]

Always use const on function parameters passed by reference or pointer when their contents (what they point to) are intended NOT to be changed. This way, it becomes obvious when a variable passed by reference or pointer IS expected to be changed, because it will lack const. In this use case const prevents accidental side effects outside the function. It is not recommended to use const on function parameters passed by value, because const has no effect on the caller: even if the variable is changed in the function there will be no side effects outside the function. See the following resources for additional justification and insight: "Google C++ Style Guide" "Use of const" section "Tip of the Week #109: Meaningful const in Function Declarations" Adisak's Stack Overflow answer on "Use of 'const' for function parameters" "Never use top-level const [ie: const on parameters passed by value] on function parameters in declarations that are not definitions (and be careful not to copy/paste a meaningless const). It is meaningless and ignored by the compiler, it is visual noise, and it could mislead readers" (https://abseil.io/tips/109, emphasis added). The only const qualifiers that have an effect on compilation are those placed in the function definition, NOT those in a forward declaration of the function, such as in a function (method) declaration in a header file. Never use top-level const [ie: const on variables passed by value] on values returned by a function. Using const on pointers or references returned by a function is up to the implementer, as it is sometimes useful. TODO: enforce some of the above with the following clang-tidy options: https://clang.llvm.org/extra/clang-tidy/checks/readability-avoid-const-params-in-decls.html https://clang.llvm.org/extra/clang-tidy/checks/readability-const-return-type.html

下面是一些演示上述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();

复制/ PASTE黑的外星人探索铝

关键词:const在函数形参中的应用;编码标准;C和c++编码标准;编码规则;最佳实践;代码标准;Const返回值

原因是形参的const只在函数内局部应用，因为它处理的是数据的副本。这意味着函数签名实际上是相同的。不过，经常这样做可能是不好的风格。

我个人倾向于不使用const，除了引用和指针形参。对于复制的对象来说，这并不重要，尽管它可以更安全，因为它表明了函数中的意图。这真的是一个主观判断。我倾向于使用const_iterator，但当循环某些东西时，我不打算修改它，所以我猜每个人都有自己的，只要严格维护引用类型的const正确性。

当我以编写c++为生时，我尽可能地压缩了所有东西。使用const是一种帮助编译器帮助你的好方法。例如，const你的方法返回值可以避免你输入错误，例如:

foo() = 42

你的意思是:

foo() == 42

如果foo()被定义为返回一个非const引用:

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

编译器很乐意让您为函数调用返回的匿名临时对象赋值。使其为const:

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

消除了这种可能性。

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

在代码中为通过value传递的内在类型参数添加多余的const会使API变得混乱，同时对调用者或API用户没有任何有意义的承诺(它只会阻碍实现)。

在一个不需要的API中有太多的“const”就像“狼来了”一样，最终人们会开始忽略“const”，因为它到处都是，大多数时候没有任何意义。

在API中，将"推理还原"参数转化为额外的const参数对前两点来说是好的，如果更多的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”使得第二行有潜在的危险!

Why?

对第一个参数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的人声称这是一件好事，因为它允许你只在定义中使用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没有任何区别。将按值传递的参数声明为const基本上没有任何意义。