企业官网建设流程全解析

• 开发工具
• 静态分析
• 代码质量
• 质量保障

导读

redundantCopyLocalConst是 cppcheck 静态分析器中一项面向 C++ 代码的性能优化检查：当局部变量被声明为const，并且只是从某个存活时间更长的对象拷贝一份只读副本时，它建议改用const引用，从而完全省去一次对象拷贝。本文以 redundantCopyLocalConst.md 官方文档为骨架，结合 lib/checkother.cpp 的实现与 test/testother.cpp 的测试用例，完整讲解该检查器的检测规则、触发条件、修复方法、启用方式与已知边界，帮助你读懂警告、消除性能隐患，并避免误用。

检测项速览

根据官方文档，该检查器的基本信息如下：

该检查器由CheckOther检查类实现，在 lib/checkers.cpp 的检查器清单中登记为"CheckOther::checkRedundantCopy","c++,performance,inconclusive"，同时在 lib/checkersidmapping.cpp 的 ID 映射表中也有记录，属于稳定的公开检查器 ID。

检测的问题：只读副本是白费的拷贝

问题本质

文档原文给出的定义是：一个局部变量被声明为const，并且初始化为一个存活时间更长的既有对象的拷贝。由于这个拷贝永远不会被修改，那么一个const引用就能做到同样的事情，却完全不需要拷贝。

#include <string> void f(std::string str) { std::string s2 = str; // <- 's2' 从未被修改 }

这里s2是str的一份完整拷贝，且声明为const后只被读取。拷贝一个std::string（或容器、任何非平凡类型）需要分配内存、逐字节复制，而读者眼中const&与const值的行为完全一致——这是典型的“拷贝了却从未写过”的冗余开销。

为什么值得修复

文档中的 Motivation 讲得很清楚：当拷贝对象只被读取时，拷贝它只会白白消耗时间和内存。将const std::string s2 = str;改成const std::string& s2 = str;后：

• 不再触发一次深拷贝（对std::string意味着省去一次堆内存分配与复制）；
• 语义不变：通过const&读到的内容与通过const值读到的一致；
• 无需改变任何读取代码。

如何修复

官方文档示例

Before（有问题的写法）：

#include <string> void f(std::string str) { std::string s2 = str; // <- 's2' 从未被修改 }

After（修复后的写法）：

#include <string> void f(const std::string& str) { const std::string& s2 = str; }

修复包含两个层面：局部变量s2改为const std::string&；同时把参数str本身也改为const std::string&（作为值参数传入本身也是一次拷贝，测试中该场景对应的警告信息正是针对拷贝点s2发出的）。

更多可修复形态

从测试用例 test/testother.cpp 可以看出，除了类型 变量 = 表达式;的赋值初始化，拷贝构造初始化同样会被检出：

class A { public: A() {} char x[100]; }; const A& getA(){static A a;return a;} int main() { const A a = getA(); // 报 redundantCopyLocalConst return 0; }

以及：

const std::string& f() const { return str; } void f(const S* s) { const std::string v{ s->f() }; // 花括号初始化，报 redundantCopyLocalConst if (v.empty()) {} }

对应测试断言（test/testother.cpp）：

[test.cpp:6:23]: (performance, inconclusive) Use const reference for 'v' to avoid unnecessary data copying. [redundantCopyLocalConst] [test.cpp:10:23]: (performance, inconclusive) Use const reference for 'w' to avoid unnecessary data copying. [redundantCopyLocalConst]

也就是说，=初始化、( )构造初始化、{ }列表初始化三种形态都能被识别。

源码实现原理

入口与前置条件

检查入口是CheckOtherImpl::checkRedundantCopy()，位于 lib/checkother.cpp。函数开头先做三道门控：

if (!mSettings.severity.isEnabled(Severity::performance) || mTokenizer->isC() || !mSettings.certainty.isEnabled(Certainty::inconclusive)) return;

即：

1. 性能类警告必须开启（对应--enable=performance）；
2. 纯 C 代码直接跳过（isC()为真则返回），所以该检查实际只对 C++ 生效；
3. 必须启用 inconclusive 置信度（对应--inconclusive），因为该检查自 #5618 起被标记为不确定结论（见 lib/checkother.cpp 的注释）。

三者缺一，检查器都会静默返回，这也是很多用户“写了同样代码却不出警告”的常见原因。

变量筛选

随后遍历符号数据库中的所有变量（symbolDatabase->variableList()），跳过以下情况（lib/checkother.cpp）：

• 已经是引用或指针的变量；
• 既无类型、又不是 STL 类型、也不是容器的变量（即基础类型基本不参与——测试用例也证实const int a = getA();这类内建类型不会触发，见 test/testother.cpp）；
• 非const且变量会被修改的。

值得注意的是，isLargeObject是前提之一（lib/checkother.cpp）：只有当对象大小大于2 * sizeof(pointer)（按目标平台指针大小估算）时才认为是“大对象”，值得提示改用引用。这也是为什么const int a = getA();不会报警——拷贝一个int的成本可以忽略。

两种触发路径

候选变量确定后，checkRedundantCopy检查初始化的右操作数，命中以下两条路径之一即报警（lib/checkother.cpp）：

路径一：函数返回引用（checkFunctionReturnsRef，lib/checkother.cpp） 右操作数是某函数(...)调用，且满足：调用形式是完整的函数(...)（表达式未被+3等运算包裹）、通过.访问成员返回的引用在读取期间变量不会被改写、函数定义中确实return 引用、且返回的是大对象。

路径二：变量直接赋值（checkVariableAssignment，lib/checkother.cpp） 右操作数是某个变量，且满足：左值（const 变量）与右值类型一致、右值是大对象、拷贝点之后到作用域结束该变量从未被改写、右值变量是局部变量或（非引用的）函数参数。

报告格式

命中后调用redundantCopyError（lib/checkother.cpp）发出性能类警告，完整消息为：

Use const reference for '$symbol' to avoid unnecessary data copying. The const variable '$symbol' is assigned a copy of the data. You can avoid the unnecessary data copying by converting '$symbol' to const reference.

ID 为redundantCopyLocalConst，关联 CWE-398，置信度标记为inconclusive。

误报防护：测试用例中的边界场景

redundantCopyLocalConst有大量历史误报修复记录在案，测试套件 test/testother.cpp 的checkRedundantCopy()用例是理解其边界的最佳教材：

理解要点：cppcheck 只有确信把值改成const&后语义完全等价时才报警。凡是将拷贝移除可能导致悬垂引用（如临时对象成员）、别名问题（如成员函数可能改写底层对象）或行为变化（如拷贝后对象才被修改、需要保留旧值）的场景，都会被误报防护逻辑拦下。这也是该检查器标记为inconclusive的原因——即使触发条件全部满足，也建议人工确认被引用对象的生命周期覆盖了引用的使用范围。

如何启用

由于该检查依赖性能告警与 inconclusive 置信度，完整启用命令为：

cppcheck --enable=performance --inconclusive your_file.cpp

• --enable=performance打开性能类检查（默认的--enable=all也包含）；
• --inconclusive允许输出不确定结论的警告，该参数在 cli/cmdlineparser.cpp 中实现，对应mSettings.certainty.enable(Certainty::inconclusive)；
• 检查器是 C++ 专属，对.c文件不会生效。

官方手册示例（cli/cmdlineparser.cpp）：

cppcheck --enable=all --inconclusive --library=posix test.cpp

在测试框架中，CheckOther会单独执行checkRedundantCopy（lib/checkother.cpp），因此你也可以在自己的工程里用同样的开关组合复现本文所有示例。

抑制（Suppression）

若某个拷贝点确实需要保留（例如后续代码依赖“读旧值”），可以精确抑制该警告。仓库自身的测试配置中就有先例，test/cfg/qt.cpp 使用内联注释抑制：

// cppcheck-suppress redundantCopyLocalConst

此外也可以用命令行按 ID 全局抑制：

cppcheck --suppress=redundantCopyLocalConst your_file.cpp

redundantCopy等其他性能类检查 ID 同样出现在 lib/settings.cpp 的抑制名单中，表明--suppress与内联cppcheck-suppress均受支持。

与相关检查器的关系

官方文档在 Related checkers 一节中给出两条关联：

• redundantCopy.md：缓冲区（buffer）场景的同类思想——缓冲区在旧内容被读取前就被再次写入。注意该文档明确指出：在目前版本中redundantCopy消息实际上不会对任何输入产生（代码路径存在但不可达），所以它只是思想上的“缓冲区版本”，真正可用的冗余拷贝检查是redundantCopyLocalConst；
• redundantAssignment.md：普通变量被重复赋值的同类思想。

三者共同构成 cppcheck 对“写/拷贝了却没用”类冗余操作的检测家族：redundantCopyLocalConst面向 const 局部变量的冗余拷贝，redundantAssignment面向变量重复赋值，redundantCopy面向缓冲区重复写入（当前不可触发）。

实践建议与注意事项

1. 先确认生命周期：把const 值改为const&的前提是被引用对象的生命周期覆盖该引用的全部使用点。cppcheck 已对此做了大量防护（如上表误报场景），但涉及跨函数返回引用、容器元素、this成员时仍建议人工复核。
2. 大对象才值得改：实现按“对象大小 > 2 倍指针大小”过滤，int、char等内建类型不会被提示；只有std::string、容器、自定义大结构体才是重点优化对象。
3. 必须加--inconclusive：很多用户启用--enable=performance却看不到该警告，是因为遗漏了--inconclusive；而--inconclusive会同时放宽其他检查器的门槛，正式 CI 中可配合--suppress精确控制。
4. 成员函数链场景会报警但需谨慎：const std::string s = c.get();（get()返回const&，test/testother.cpp 的用例）会触发警告，但若get()的返回来自临时对象（getC().get()），改为引用反而引入悬垂——cppcheck 对此类场景做了豁免（test/testother.cpp），理解这个区别能帮你判断哪些警告值得采纳。

一句话总结：redundantCopyLocalConst用一行const&消除一次真实的对象拷贝，是 C++ 性能优化中最易自动化、最低风险的检查之一；读懂其inconclusive属性与误报防护逻辑（lib/checkother.cpp），即可在--enable=performance --inconclusive的组合下放心使用。

• 开发工具
• 静态分析
• 代码质量
• 质量保障