如何在c++中编写符合C++ Core Guidelines的代码? (现代化准则)

应使用 std::span 替代裸指针+长度参数,因其类型安全、编译期推导、零开销;禁用 new/delete,改用栈变量、std::array、std::vector、std::unique_ptr 等 RAII 方式;输入参数优先 const T& 或 T,避免非常量引用;启用 clang-tidy/CppCoreCheck 等静态检查并设为 error。

std::span 替代裸指针 + 长度参数

Core Guidelines 明确反对 T* + size_t 这种容易脱节的组合。传参时一不留神就忘记检查长度,或把指针和长度传错顺序。

改用 std::span 能让边界安全内建在类型里,编译期可推导,运行时零开销:

void process_data(std::span data) {
    for (int x : data) { /* 安全遍历 */ }
}

// 调用方自然适配 std::vector v = {1, 2, 3}; process_data(v); // OK:隐式转 span int arr[] = {4, 5}; process_data(arr); // OK:推导出长度为 2 process_data({ptr, len}); // OK:显式构造(但应尽量避免裸 ptr 构造)

注意:不要用 std::span 包裹堆分配内存(如 new int[n]),因为 std::span 不拥有资源,析构时不释放;此时该用 std::unique_ptr 或容器。

禁止使用 new/delete 手动管理内存

Core Guidelines 的 R.11 直接写明:“Don’t call new or delete explicitly”。裸 new 容易导致泄漏、异常安全问题,且无法与 RAII 自然衔接。

立即学习“C++免费学习笔记(深入)”;

替代方案按场景选择:

  • 固定大小、栈上足够 → 直接用栈变量或 std::array
  • 动态大小、需自动管理 → 优先用 std::vectorstd::string
  • 需要独占堆资源且不共享 → 用 std::unique_ptrstd::unique_ptr
  • 必须共享所有权 → 仅当明确需要时才用 std::shared_ptr,并避免循环引用

错误示例:

int* p = new int{42};
// 忘记 delete?异常跳过?都危险
return *p;
正确写法:
return std::make_unique(42); // 返回 unique_ptr,所有权清晰

函数参数优先用 const T&T,禁用 T& 输入参数

Core Guidelines 的 F.16 规定:输入参数应是只读的,除非函数语义明确要求修改调用方状态。用非 const 引用作输入,既破坏接口可读性,又阻碍传入字面量或临时对象。

常见误用:

void set_name(std::string& name); // ❌ name 是输入还是输出?不能传 "alice" 字面量
set_name("alice"); // 编译失败:不能绑定非常量引用到右值

正确方式:

  • 只读输入 → const std::string&(大对象)或 std::string(小对象,现代编译器 RVO/NRVO 优化充分)
  • 输出参数 → 显式用输出参数名(如 std::string& out_name),或更推荐返回值(std::string compute_name()
  • 移动语义输入 → 若函数要“吃掉”参数,用 std::string&&(但极少用于普通函数,多见于构造/赋值)

启用编译器静态检查并配置 /permissive-(MSVC)或 -pedantic(Clang/GCC)

Core Guidelines 不是道德规范,而是可被工具链验证的工程实践。不靠人工 review,而靠 clang-tidyCppCoreCheck(VS)、include-what-you-use 等工具落地。

关键操作:

  • Clang/GCC:加 -Wconversion -Wduplicated-cond -Wfloat-equal -Wnon-virtual-dtor 等,再配合 clang-tidy -checks="cppcoreguidelines-*"
  • MSVC:项目属性中启用 C++ Core Check,并确保 /permissive- 关闭非标准扩展(比如隐式 int 返回、宽窄字符串混用)
  • 所有项目:把 #include std::span 等现代设施纳入构建,别让团队还在用自定义 ArrayView 封装

最容易被忽略的一点:很多团队开了 clang-tidy,但没把检查结果设为 error,或者没集成进 CI。只要有一处 warning 被放过,规则就形同虚设。