17370845950

必须用 const T& 而不是 T 传参的情形是：当参数为大对象（如 std::string、std::vector、自定义类）且函数只读不修改时，为避免拷贝开销；内置类型和小结构体则优先值传递。

什么时候必须用 const T& 而不是 T

当传入的参数是大对象（如 std::string、std::vector、自定义类）且函数只读不改时，const T& 是默认选择。值传递会触发拷贝构造，开销不可忽视——比如一个 1MB 的 std::vector，每次调用都拷贝就是实打实的内存与时间浪费。

常见错误是“图省事全用值传”，尤其在循环里调用时，性能陡降却难以察觉。注意：内置类型（int、double、指针）反而推荐值传递，因为引用本身在 x86-64 上通常也是 8 字节，无优势还多一次解引用。

• std::string、std::vector、std::map 等标准容器，一律优先 const T&
• 小结构体（如仅含 2 个 int）可测一下：若 sizeof(T) ，值传更稳
• 函数签名暴露了是否修改参数语义：void f(const std::string& s) 表明不会动 s，调用方更安心

输出参数该用 T& 还是 T*

现代 C++ 中，非空输出参数首选 T&；只有需要表达“可选输出”（即允许不提供）时，才考虑 T*。用指针容易模糊意图，也增加空指针检查负担。

典型反例：bool parse(const std::string& s, int* out_val) —— 调用方得传 &x，还可能误传 nullptr；而 bool parse(const std::string& s, int& out_val) 强制绑定有效变量，语义清晰，编译器也能更好优化。

• 输出参数必须写入：用 T&，例如 void split(const st

  

  d::string&, std::vector<:string>& parts)
• 输出参数可选（函数可能跳过写入）：用 T*，但需文档明确说明 null 合法
• 想同时支持输入+输出？别这么做。拆成两个参数或改用返回结构体（如 std::tuple 或自定义 struct）更安全

移动语义下，T&& 参数要不要加 const

不要加 const。写成 const T&& 会禁用移动操作，退化为只读右值引用，几乎无实用场景。真正需要的是完美转发或资源接管，此时必须是 T&&（非 const）。

典型误用出现在想“既接收右值又不修改”的场合——但右值本就预期被移动，加 const 只会让 std::move(x) 失效，编译器只能调用拷贝构造而非移动构造。

• 只用于转发：用 template void f(U&& u) + std::forward(u)
• 只接收右值并移动：用 void f(T&& t)，内部调用 t.some_expensive_operation() 或 std::move(t)
• 如果函数逻辑上“只读右值”，说明它其实不该接受右值——应统一用 const T&

混合参数场景：一个函数既有输入又有输出，怎么组织

避免把输入和输出参数混在同一函数里，尤其是当它们生命周期或所有权关系不清晰时。C++ 没有标注“输入/输出”的语法糖，靠命名和顺序极易出错。

比如 bool transform(std::vector& in_out, const std::string& config)，调用方无法一眼看出 in_out 是被清空重填，还是追加，还是原地修改。更糟的是，若 config 内部持有对 in_out 的引用，就可能引发悬垂。

• 优先返回新对象：std::vector transform(const std::vector& input, const Config& c)
• 若必须复用内存（如性能敏感循环），用明确命名的输出参数：void transform_to(const std::vector& input, std::vector& output, const Config& c)
• 绝不在同一参数上叠加输入+输出语义（即所谓“inout”参数），除非是极底层、有充分文档和测试保障的接口

最易被忽略的一点：参数顺序影响可读性。把 const 输入放前面，非常量输出放后面，符合从左到右“数据流”直觉。但这只是习惯，真正关键的是——每个参数的语义必须在函数名和类型中自解释，不能靠位置猜。