现代C++ | 基础革命特性

目录前言类型别名 (using)decltpye类型推导auto 类型推导尾置返回类型nullptr统一初始化{} 初始化列表default / delete显式控制特殊成员函数委托构造函数继承构造函数原始字符串字面量static_assert编译期检查enum class强枚举属性 (Attributes)前言C98/03 最大的痛点就是写代码太啰嗦、容易出错、安全隐患多类型要重复写、初始化方式乱、空指针不安全、枚举能隐式转 int、断言只能运行时等等。 C委员会在 2005-2010 年间决定“一次解决这些基础问题”。目标是让日常代码立刻变短 30-50%安全性大幅提升同时保持零开销编译后和手写一样快。Bjarne Stroustrup 当时说“C 要想不被 Python/C# 淘汰就必须先把基础写法现代化。”类型别名 (using)设计原因typedef 语法笨拙无法支持模板别名。底层原理using 是第一类别名声明支持模板参数。实际例子// C98 typedef typedef std::vectorint VecInt; // C11 using支持模板 templatetypename T using Vec std::vectorT; using StringMap std::mapstd::string, int;using 和 typedef 最大区别是什么using 支持别名模板decltpye类型推导设计原因为了在编译期不求值地获取任意表达式的精确类型包括引用、const/volatile 限定符。底层原理decltype是一个编译期类型查询运算符它的核心特点是不求值只分析表达式的类型不会真正执行表达式因此没有任何运行时开销且保留完整类型信息会保留表达式的const、volatile以及引用属性。实际代码例子int a 10; double b 3.14; const std::string s hello; // 1. 推导变量的类型 decltype(a) x 20; // x 是 int decltype(s) y world; // y 是 const std::string保留 const // 2. 推导表达式的类型 decltype(a b) z 5.5; // ab 是 doublez 是 double decltype(a b) flag; // ab 是 boolflag 是 bool常见坑decltype((x)) 和 decltype(x) 结果不同decltype(x)单纯看变量x是什么类型。decltype((x))看表达式(x)的值类别左值 / 右值左值则加引用。int x 0; // 1. decltype(实体名)推导实体的声明类型 decltype(x) a x; // a 的类型是 int // 2. decltype(表达式)若表达式是左值推导为左值引用 decltype((x)) b x; // b 的类型是 int因为 (x) 是一个左值表达式decltype和auto有什么区别推导规则不同auto会去除引用、const、volatile属性除非你显式加上或const。decltype会保留表达式的原始类型包括引用、const/volatile限定符统统保留。auto 类型推导设计原因以前写迭代器或模板类型要敲几十个字符太烦。底层原理auto 是编译期占位符和 template 一样用模板参数推导规则。编译器看到初始化表达式就直接把 auto 替换成真实类型运行时零开销。实际老代码 vs 新代码例子// C98超级长 std::mapstd::string, std::vectorint::const_iterator it m.begin(); // C11一句话 auto it m.begin(); // auto decltype(m.begin()) it2 m.begin(); // 需要保留精确类型时用auto 底层原理是什么会影响性能吗编译期替换成真实类型和手写一模一样零开销。什么时候不能用 auto公开接口的函数参数公开接口别用即使 C20 允许公开接口头文件也别用因为调用者无法直观知道参数类型严重影响可读性和维护性。初始化列表的 “坑”auto x {1, 2, 3};会推导为std::initializer_listint而非数组或容器C11/14 中auto x{1};也会推成std::initializer_listintC17 后才修正为int需注意版本差异。需要保留数组类型时数组用auto推导会退化为指针int arr[5] {1,2,3,4,5}; auto a arr; // 推成 int*丢失数组长度信息若需保留数组类型需用引用auto a arr;。显式类型转换需求当需要特定类型如float而非double、char而非int时auto可能推导为默认类型auto f 3.14; // 推成 double而非 float auto c a 1; // 推成 int而非 char类的非内联静态成员变量类内声明非内联静态成员时不能用autoconstexpr静态成员除外class A { static auto x; // 错误类内非内联静态成员不能用 auto static constexpr auto y 10; // 正确constexpr 允许 }; int A::x 10; // 类外定义时需显式指定类型虚函数的协变返回类型派生类重写虚函数时若需返回协变类型派生类指针 / 引用不能用auto——auto会推导为基类类型丢失协变特性class Base { virtual Base* clone() 0; }; class Derived : public Base { auto clone() override { return new Derived; } // 错误推成 Base*非协变 Derived* clone() override { return new Derived; } // 正确 };尾置返回类型设计原因auto 只能推导变量复杂模板函数返回类型无法在前置位置写 decltype。底层原理decltype 不求值直接在编译期拿到表达式的精确类型包括引用、const、volatile。尾置返回类型允许在参数列表后用 auto decltype。实际代码例子// C98/03 老写法无法写 templatetypename T, typename U ??? add(T a, U b) { return a b; } // 无法在前置位置写返回类型 // C11 新写法 templatetypename T, typename U // 这里的auto只是一个占位符真正的返回类型由 - 后面的部分指定 auto add(T a, U b) - decltype(a b) { // 尾置返回类型 return a b; } // C14 后更简洁返回类型自动推导 templatetypename T, typename U auto add(T a, U b) { return a b; }什么时候必须用 C11 的尾置返回类型而不能用 C14 的auto当返回类型的推导逻辑非常复杂或者需要根据decltype精确控制引用 /const 属性时C11 的写法更稳妥。例如在某些泛型容器的迭代器返回中你可能需要严格返回iterator或const_iterator此时显式的decltype更清晰。nullptr设计原因NULL 其实是 0int重载函数容易出 bug。底层原理nullptr 是新关键字类型是 std::nullptr_t是编译器内置的右值常量只能转成指针不能转 int编译器内置支持从根源上杜绝空指针的语义歧义只要是表示空指针一律用nullptr彻底抛弃NULL。实际例子// 老代码危险 void f(int); void f(int*); f(NULL); // 意外调用 int 版本 void f(nullptr); // C11 安全必走指针版本nullptr是编译期常量还是运行期变量编译期常量。编译器会直接将其处理为特定的 “空指针标记”不占用运行期内存。sizeof(nullptr)等于多少等于sizeof(void*)因为std::nullptr_t虽然是空类型但作为指针类型的 “占位符”其大小与普通指针一致。C11 之前没有nullptr怎么安全表示空指针老代码常用(void*)0或自定义宏如#define NULLPTR (void*)0但都不如nullptr类型安全。统一初始化{} 初始化列表设计原因以前初始化方式、()、构造函数乱七八糟还允许窄化转换丢精度。底层原理{} 是统一语法优先找 initializer_list 构造函数禁止窄化转换编译期报错。实际例子// 老代码 int x 3.14; // 静默丢精度 int a{5}; std::vectorint v{1,2,3,4,5}; // 最优雅 int y{3.14}; // 编译错误防窄化 // {} 有两种形式C11/14/17 有细微差异对explicit构造函数的限制直接列表初始化允许使用explicit构造函数拷贝列表初始化禁止使用explicit构造函数编译报错。这是最本质的差异源于explicit的设计初衷禁止隐式转换。#include vector class ExplicitClass { public: // explicit 构造函数禁止隐式转换 explicit ExplicitClass(int x) { std::cout explicit 构造\n; } ExplicitClass(std::initializer_listint list) { std::cout initializer_list 构造\n; } }; // 直接列表初始化允许 explicit 构造函数 ExplicitClass obj1{10}; // 输出explicit 构造优先匹配单参数构造而非 initializer_list ExplicitClass obj2{1,2,3}; // 输出initializer_list 构造 // 拷贝列表初始化禁止 explicit 构造函数 // ExplicitClass obj3 {10}; // 编译报错无法隐式调用 explicit 构造函数 ExplicitClass obj4 {1,2,3}; // 没问题initializer_list 构造函数不是 explicitC11/14/17中的auto的类型推导规则C11/14 中无论直接还是拷贝列表初始化auto都会优先推导为std::initializer_listT#include initializer_list auto x1{1}; // C11/14推成 std::initializer_listint坑 auto x2 {1}; // C11/14推成 std::initializer_listint auto x3{1,2,3}; // C11/14推成 std::initializer_listint auto x4 {1,2,3};// C11/14推成 std::initializer_listintC17 对auto的列表初始化推导规则做了颠覆性修改严格区分直接列表初始化和拷贝列表初始化的auto推导直接列表初始化auto x{...}只能有单个元素推导为该元素的类型若有多个元素编译报错。拷贝列表初始化auto x {...}保持 C11/14 规则推导为std::initializer_listT元素类型需一致。#include initializer_list // 直接列表初始化C17 auto x1{1}; // 推成 int单个元素 // auto x2{1,2}; // 编译报错直接列表初始化 auto 不能有多个元素 // 拷贝列表初始化C17 auto x3 {1}; // 推成 std::initializer_listint auto x4 {1,2}; // 推成 std::initializer_listint // auto x5 {1, 2.0}; // 编译报错元素类型不一致{} 初始化有什么好处统一写法 禁止窄化 支持列表初始化最安全。std::initializer_list可以移动吗不能。因为它的底层数组是const T[]且initializer_list只持有指针和长度没有所有权 —— 移动它和拷贝它的代价一样只是复制指针和长度且无法转移底层数组的所有权。default / delete显式控制特殊成员函数设计原因C98/03 时代如果你想禁止拷贝构造或赋值只能把它们声明为 private 且不实现代码丑陋、错误信息差、维护困难。C11 希望让程序员显式控制编译器是否生成默认特殊成员函数。底层原理default 让编译器生成和自动生成完全一样的代码零开销delete 在编译期就把该函数标记为已删除任何调用都会直接编译错误。新旧代码对比// C98 老写法 class NonCopyable { private: NonCopyable(const NonCopyable); // 只有声明 NonCopyable operator(const NonCopyable); }; // C11 新写法 class NonCopyable { public: NonCopyable() default; NonCopyable(const NonCopyable) delete; NonCopyable operator(const NonCopyable) delete; ~NonCopyable() default; // 显式要默认析构 };default 生成的代码和自动生成完全一样delete 是编译期错误比 private 未定义的链接期错误更好。常见坑delete 必须写在声明处不能写在定义处对虚函数使用时要注意。为什么推荐 delete 而不是 private 未定义delete 在编译期就报错错误信息清晰且包含调用位置private 未定义是链接期错误信息模糊且难以定位。Rule of Five 里哪些函数通常要 delete拷贝构造和拷贝赋值当类管理资源时。委托构造函数设计原因同一个类多个构造函数经常重复初始化成员代码容易出错且违反 DRY 原则。底层原理允许一个构造函数在初始化列表中直接调用同类的另一个构造函数委托编译器保证委托链只执行一次避免多次初始化。实际例子class Widget { int x, y; std::string name; public: Widget(int a, int b, std::string n) : x(a), y(b), name(std::move(n)) { // 公共初始化逻辑 } Widget() : Widget(0, 0, ) {} // 委托 Widget(int a) : Widget(a, 0, ) {} // 委托 Widget(std::string s) : Widget(0, 0, std::move(s)) {} };委托构造函数和继承构造函数的区别委托是同一个类内的调用继承是把基类构造函数引入派生类。继承构造函数设计原因派生类想直接复用基类所有构造函数时不想手写一大堆转发构造函数。底层原理using Base::Base; 把基类所有构造函数“继承”到派生类C17 修复了多继承和模板场景的歧义。实际例子struct Base { Base(int x, double y) { /* ... */ } Base(std::string s) { /* ... */ } }; struct Derived : Base { using Base::Base; // 自动继承所有构造函数 // 无需再写 Derived(int, double) 等转发函数 };原始字符串字面量设计原因C11 之前编写包含大量反斜杠\、引号或多行文本的字符串如 Windows 路径、正则表达式、JSON/XML堪称 “转义符地狱”。原始字符串字面量Raw String Literals 的引入彻底解决了这一痛点让代码回归直观。实际例子语法Rdelimiter(原始内容)delimiter R固定前缀表示 Raw String。 delimiter可选自定义分隔符用于避免字符串内部出现 ) 时的冲突默认空。 (...)括号内的内容会被原样保留无需任何转义 std::string path R(C:\Users\test\file.txt); std::string regex R((a|b)?\d{3});原始字符串可以和u8UTF-8、uUTF-16、UUTF-32、L宽字符前缀结合// C11UTF-8 原始字符串 std::string utf8_str u8R(C:\用户\测试.txt); // C17u8 前缀更规范配合 char8_t // std::u8string utf8_str u8R(C:\用户\测试.txt);如果原始字符串内部需要包含 ) 字符比如某些复杂的正则或代码片段默认的R(...)会提前结束字符串。此时需要自定义分隔符// 错误示例字符串内部有 )会导致编译错误 // std::string bad R(Here is a ) and more); // 正确做法自定义分隔符比如用 Wangzn2016 std::string good RWangzn2016(Here is a ) and more)Wangzn2016; std::cout good std::endl; // 输出Here is a ) and morestatic_assert编译期检查设计原因老assert只在Debug模式下且是运行时有效采用预处理指令来排除错误又太局限。底层原理C11 内置的关键字编译器在编译时计算表达式必须是编译期就能算出结果的常量表达式如果是false就打印消息并停止编译true则什么都不做。老代码例子// 实际上 #error 根本看不懂 sizeof这代码在 C 里是错的 #if sizeof(int) ! 4 #error int 必须是 4 字节 #endif /* #error 有3 个致命缺陷 只能做最简单的文本 / 宏检查它看不懂 sizeof、看不懂表达式只能看宏定义。 没法和 C 模板配合模板是编译期生成代码的#error 根本插不上手。 错误信息很难读只是简单的一行文本没法告诉你 “到底哪里错了”。 */现代C中static_assert的例子static_assert(sizeof(int) 4, int 必须是 4 字节); // 检查模板类型是不是 int template typename T void f(T x) { static_assert(sizeof(T) sizeof(int), T 必须和 int 一样大); }static_assert和assert有什么区别static_assert编译期间就检查错误不占程序运行速度提前发现问题更安全。enum class强枚举设计原因老 enum 会污染命名空间、能隐式转 int容易比错。底层原理enum class 是强类型不隐式转换必须 static_cast。static_assert 是编译期断言。老代码例子// C 语言 enum Color { RED, // 0 GREEN // 1 }; enum Color c RED; int x RED; // 可以直接变成 int有 3 个大问题名字会污染全局你写了RED整个程序都能用很容易重名。能偷偷变成 int本来是颜色结果能直接当数字用容易写错代码。不同枚举能乱比较RED 0居然是对的非常不安全。C11给了个更安全的版本enum class强枚举。规则只有 2 条C 语言基础就能懂enum class Color { Red, Green };必须写 枚举名值Color c Color::Red;不能偷偷变成 int// int x Color::Red; // 错误 int x static_castint(Color::Red); // 必须手动转enum class 和 enum 区别为什么推荐用enum class老 enum 会污染命名空间且能偷偷隐式转 int 不安全enum class 是强类型必须加枚举名::使用且禁止隐式转 int更安全所以强烈推荐用 enum class。属性 (Attributes)设计原因在 C11 之前编译器厂商通过各自的扩展如 GCC 的__attribute__、MSVC 的__declspec提供代码提示或优化指令导致代码可移植性极差。在 C11 之前若想让编译器提示 “这个函数返回值必须使用”不同编译器写法完全不同这种碎片化导致代码难以维护和移植// GCC/Clang 扩展 __attribute__((warn_unused_result)) int func(); // MSVC 扩展 _Check_return_ int func();C11 引入的标准属性用统一的[[...]]语法解决了这一问题属性的基本语法非常简单[[属性名]] 或 [[属性名(参数)]]位置可放在函数、变量、类、枚举、语句等几乎任何实体上。多个属性用逗号分隔如[[nodiscard, deprecated]]。命名空间支持编译器特定扩展如[[gnu::unused]]、[[msvc::forceinline]]。C11[[noreturn]]—— 标记 “永不返回” 的函数用于表示函数不会正常返回如直接终止程序、抛出异常后不恢复帮助编译器优化代码并消除 “缺少返回值” 的警告。#include stdexcept #include cstdlib // 标记这个函数永远不会返回到调用点 [[noreturn]] void fatal_error(const std::string msg) { throw std::runtime_error(msg); // 抛出异常后不返回 } [[noreturn]] void exit_program() { std::exit(1); // 直接终止程序 } int main() { // 编译器知道这里不会继续执行不会警告“main 缺少返回值” fatal_error(something went wrong); }C14[[deprecated]]—— 标记 “已弃用” 的 API用于提示用户某函数、类或变量已过时建议使用新接口可附带自定义提示信息。#include iostream // 简单标记已弃用 [[deprecated]] void old_api() { std::cout old api std::endl; } // 带提示信息告诉用户用什么替代 [[deprecated(use new_func() instead)]] void legacy_func() { std::cout legacy func std::endl; } int main() { old_api(); // 编译时会警告old_api is deprecated legacy_func(); // 编译时会警告并显示提示信息 return 0; }C17[[nodiscard]]—— 强制检查返回值用于标记函数返回值必须被使用如工厂函数、状态检查函数忽略返回值会触发编译器警告。#include memory #include optional // 场景1工厂函数返回值必须接收 [[nodiscard]] std::unique_ptrint create_object() { return std::make_uniqueint(42); } // 场景2状态检查函数返回值不能忽略 [[nodiscard(必须检查初始化是否成功)]] bool init_system() { return true; } int main() { create_object(); // 警告返回值被忽略 init_system(); // 警告返回值被忽略并显示自定义提示 // 正确用法 auto obj create_object(); if (init_system()) { /* ... */ } return 0; }C17[[fallthrough]]—— 显式标记 switch 穿透用于在switch语句中显式表示 “故意穿透”消除编译器对隐式穿透的警告提高代码可读性避免 bug。#include iostream void handle_case(int n) { switch (n) { case 1: std::cout case 1\n; [[fallthrough]]; // 显式告诉编译器我是故意穿透到 case 2 的 case 2: std::cout case 2\n; break; // 正常 break不会穿透 case 3: std::cout case 3\n; // 这里没有 [[fallthrough]] 也没有 break编译器会警告 default: std::cout default\n; } } int main() { handle_case(1); // 输出 case 1 和 case 2 return 0; }