“C 和 c”这两个词放在一起乍一看像程序员之间才懂的冷笑话。但如果你真在代码里和它们长期打交道会发现这个标题里藏着的是一语三关C 是一门语言名字c 是一个具体的自增表达式而把“C”这个单词重新拆开时它自己也是一个“后缀递增操作符”的变体。很多人刚接触时会把语言名和运算符混在一起甚至在面试、笔试里被“c 和 c 有什么区别”这种题绕晕。这篇不是我打算从语法表上抄一段标准答案就想按一个从业者的理解把二者背后的历史、语义、性能和坑都摊开讲一讲。适合读这篇的不只是正在学 C 的初学者也包括写了几年 C 但未必深究过前缀自增细节的人。标题里这个“c”看着简单但它牵扯到值类别、求值顺序、运算符重载、未定义行为甚至能延伸到语言标准演进。读完之后你再看“C”三个字母感觉会完全不一样。1. 语言名里的彩蛋为什么叫 C以及 c 的第一次相遇1.1 C 的名字本身就是一次运算C 的前身叫“带类的 C”改名成 C 是在 1983 年前后。当时参与语言设计的一位开发者喜欢开玩笑借用了 C 语言里的自增运算符“”把名字写成“C 的自增”意思是“在 C 的基础上向前走一步”。这个命名很有幽默感也很有信息量它用一个运算符描述了语言和前辈的关系而不是另起炉灶造一个抽象词。有意思的是名字里的“”是放在 C 后面的严格说是“后缀自增”。如果按运算符语义来理解c表达式的值是“自增前的旧值”副作用是“让 c 本身加一”只不过这个“加一”发生在后续某个求值时间点。把这种语义映射到语言上会得到一种很妙的解释你先拿到的是老 C 语言副作用是得到一门增强了的新语言。也就是说C 这个名字天然地带着“从旧到新、从 C 到 C”的时间感。那你再看标题里的c它是前缀自增正好反过来先执行副作用把变量加一之后再取新值。当年取名字的人多半没想过要和运算符语义严格对齐但这两者的差异恰好构成一个有趣的对照——C 这个名字选中了“后置”而普通代码里我们写的c是“前置”。一个是语言命名一个是日常操作符号相同解读不同就这么凑在了一起。1.2 当我们写下 c 时写的到底是什么在代码层面c是一个表达式含义是对变量 c 执行自增副作用然后让整个表达式的值是自增后的新值。比如int c 10; int n c;执行完之后 c 变成 11n 也变成 11。很多人第一次接触时容易把它读成“c 加加”然后误以为c就是“C 语言”。其实语言名 C 不是一个表达式它只是长得像表达式而c是真会修改内存里数据的操作。从符号学角度这三层关系很清楚C是语言标识符c是运算符表达式C则可能是变量名、类型名或语言名字。同一个“”在不同位置、不同语境里扮演着完全不同角色。这种多义性正是 C/C 体系里常见的一种“令人头疼又令人兴奋”的特性。1.3 三种层次的读者三种理解方式我见过完全不写代码的人看到“C 和 c”只会觉得是乱码也见过学 Python 出身的初学者把 C 当成“某种高级语言”把 c 当成“一个奇怪的写法”而真正写 C 的老手看到这个标题第一反应是“前缀和后缀的区别”第二反应是“语言为什么叫 C”第三反应才会去看题目里有没有陷阱。这种层次感本身很有价值。它提醒我们很多基础概念不需要死记硬背从名字和符号的来龙去脉去理解反而记得更牢。接下来的内容我会把c这个“表达式”彻底拆开再把“为什么推荐在代码里多用c”这件事讲明白。2. c 的执行细节前置自增不是换个位置那么简单2.1 五个必须记住的语义点要真正掌握c下面这几点缺一不可自增副作用发生在“读取表达式结果”之前。整个表达式的值是自增后的新值。对内置类型来说表达式结果在 C11 之后是左值。操作数必须是一个可修改的左值不能写5这种明显无效的表达式。它等价于c 1而c等价于(c 1) - 1这种取旧值的过程。第一点和第三点是重中之重。比如下面这段代码int c 7; int* p (c); // 合法c 是左值可以取地址 int* q (c); // 不合法c 的结果是右值第二行能编译第三行会报错。报错信息通常是“无法将右值绑定到指针”之类。这个区别在日常业务代码里未必常见但在泛型编程、模板元编程里它是判断某个表达式能不能被安全引用的关键。2.2 前置和后置的直观差异如果用一句话概括c是“我先给你加好再把新值拿给你”c是“我先把旧值拿给你回头我再自己加”。对应到实际使用c适合你根本不在乎旧值的场景比如循环步进、迭代器前进、计数器累加。c适合你需要“操作前的状态”的场景比如v[i] x想把 x 写到下标 i 处同时让 i 自增。看这段代码就更直观int i 0; int a i; // a1, i1 int b i; // b1, i2a 和 b 虽然同样是 1但背后的时序完全不同。正因为i需要先保留旧值在类类型昂贵时它会比i多一次拷贝这在标准库迭代器里体现得很明显。2.3 为什么 c 的结果可以是左值C11 之前内置类型的前缀自增结果是不是左值标准里没那么明确很多老书也写得含糊。C11 正式规定c的结果是左值c的结果是右值。这一改变让泛型代码里可以统一通过x拿到可写引用也让连续自增成为可能。看下面这个写法int c 0; c; // 合法先 c 得到左值再对左值 最终 c2但你不能写c。因为c的结果是右值右值不能再做非成员自增。这个例子特别适合用来检验自己是不是真懂了左值右值而不是只会在面试题里背概念。3. 性能与习惯为什么代码规范总推荐 c3.1 内置类型没有肉眼可见的性能差很多人一开始会纠结c真的比c快吗对 int、double 这类内置类型答案是在现代优化编译器里单条语句的c和c生成的机器码几乎完全一样。你可以分别写这两行再反汇编看看int c 0; c; c;在没有开优化时两条语句可能都对应一个inc指令开了优化后如果结果没被使用编译器甚至直接把两条都优化掉。对内置类型性能不该成为你选前置还是后置的理由真正的理由在语义一致性。3.2 迭代器和类类型的差别才是关键一旦操作对象是迭代器、智能指针、或者任何定义了自增运算符的类类型后置自增就会暴露它笨重的一面。因为标准语义要求c返回“自增前的旧值”很多实现必须临时构造一个副本再对原对象做自增最后返回那个临时副本。想象一个链表迭代器内部保存着当前节点指针。如果v.end()这种迭代器本身只是单个指针拷贝成本不高但如果是一个内部持有多个成员、或者带有共享资源管理的迭代器每次c就可能触发一次拷贝构造甚至一次引用计数增减。我自己写泛型循环时长期坚持一个习惯遍历时不用it统一写it。这不是教条是为了让代码在不同容器、不同迭代器实现下都能获得稳定的行为。你不会知道哪天别人会把你的vector迭代器换成一个自定义的代理迭代器那时每个it都会实打实多一笔开销。3.3 从老规矩到新习惯你可能在旧代码里见过这种风格for (std::vectorint::iterator it vec.begin(); it ! vec.end(); it)这段在单线程里运行没问题但如果被 code review 较真大概率会被建议改成it。现代 C 里range-based for 已经帮我们屏蔽掉了大量手写迭代器循环但在算法库自定义迭代器、或者底层容器实现里你仍然躲不开自增运算符的选择。推荐的规则其实很简单默认使用c只有在“确实需要旧值”时才使用c。把这条规则当成肌肉记忆比任何性能测试都可靠。4. 运算符重载亲手实现一个 c 的正确姿势4.1 前缀和后缀的不同签名如果你想给自己写的类支持自增你需要同时实现两个版本。语法上后缀版本必须带一个 int 占位参数这是 C 为了区分两者而设计的“语言技巧”class Counter { public: explicit Counter(int v) : value(v) {} Counter operator(); // 前置 c Counter operator(int); // 后缀 c private: int value; };这个 int 参数只是用来区别签名不会真的传值进去所以你通常不会给它命名编译器也不在乎。调用时c选前置版本c选后缀版本。4.2 推荐的实现模板后缀复用前缀正确的做法不是把两份逻辑各写一遍而是让后缀版本调用前缀版本。标准做法长这样Counter Counter::operator() { value; return *this; } Counter Counter::operator(int) { Counter old *this; // 保存旧值 (*this); // 复用前置实现 return old; // 返回旧值 }这种写法的好处很明显真正修改状态的逻辑只出现在前置版本里后缀版本只负责“先拷贝再复用后返回”。这样万一以后字段变了、逻辑复杂了你只需要改一个地方两个版本的行为都会保持一致。返回值类型也不能搞错前置返回Counter允许链式修改后缀返回Counter因为它代表的旧对象本就是临时的返回引用会变成悬空引用那是未定义行为。4.3 链式自增和它的边界前置版本返回引用所以你可以写counter连续两次自增最终状态正确。后缀版本返回临时对象所以counter编译不过或者说即使编译器允许它自增的也只是一个临时对象的副本原对象根本没变。这个差异平时很少有人利用但如果你在设计一套数值类型或迭代器接口它其实是一个值得暴露给调用方的语义特征。你不仅是在重载运算符你是在决定“这个类型允许被怎样连续操作”。5. 最容易踩的坑c 相关的未定义行为与求值顺序5.1 一个表达式里别写两次同类自增C 和 C 的老开发者都听过一句话“同一个变量在一个表达式里被多次修改行为未定义。” 这句警告放在c身上再合适不过。int i 1; i i i; // 未定义行为不要问结果是多少这样的代码在标准里就是“未定义行为”编译器可以做任何事它可能算出 4可能算出 5可能在调试版里崩掉也可能在优化后直接返回一个你根本想不到的值。原因在于同一个变量 i 在一个完整表达式里被多次写而 C 没有规定这些副作用的发生顺序编译器可以自由选择生成指令的顺序和方式。5.2 C17 修正了什么又没修正什么C17 之后标准对很多运算符的求值顺序做出了明确要求比如a.b中先求 a函数调用中实参的求值顺序不再完全任意。但千万别以为 C17 把所有旧坑都填了。下面这些写法在 C17 之后的正式标准里依然是未定义行为foo(i, i); // 两个参数的求值顺序互相未规定副作用交叉 arr[i] i; // 下标和赋值目标都修改 i互相未规定 i i; // 同一个变量读改写混在一起这些代码在今天的编译器里也可能会“碰巧”给出结果但碰巧不等于合法。只要换了编译器版本、优化选项或者周围的表达式结构结果就可能变。安全边界其实非常简单一个完整表达式里同一个变量最多被写一次如果确实要连续改拆成多条语句。5.3 现场排查实录while 循环里的前缀陷阱我在实际项目里排查过一个挺有代表性的问题。某跨平台系统的日志模块里有一段循环int index 0; while (index count) { // 处理 index }新来的同事觉得index和index应该没区别改成while (index count)。结果第一条日志被跳过了边界条件也整体偏移。排查了大半天最后发现就是这个前置和后置的语义差异——前置是先自增再比较后置是先比较再自增。这个案例给我留下的教训不是“不要改代码”而是“读循环条件时先看清楚自增位置”。很多人写代码时顺手用i但在判断条件里它和i是完全不同的逻辑。这也是面试官特别喜欢考while (i)和while (i)的原因。6. 把语言名当成运算符C 自身也是一次自增6.1 标准版本一次一次地“前置自增”C 语言本身从 C98 到 C11再到 C14、C17、C20、C23每一次新标准都像是对这门语言做了一次自增操作。新特性落地并不是“下个版本才有”而是在标准发布那一刻起就成为一种新状态。如果沿用这个比喻语言演进更像c先让标准生效之后你写代码时拿到的就是新语言。C 这个名字里的“”是后缀看起来像c严格说是旧 C 之后才增强。但实际体验中每当我切换到新标准感觉更像是“前置自增”——新标准先被应用然后所有代码都在新的状态下编译运行。这个反差挺有趣也常被用来解释为什么 C 的兼容性包袱那么重你不能像c那样把语言推到新状态后就完全丢掉旧值因为太多老代码依赖那个“旧值”。6.2 标准版本速览版本主要变化C98第一个正式标准模板、STL 基础成型C11移动语义、右值引用、lambda、auto现代 C 真正的起点C14泛型 lambda、返回类型推导增强C17结构化绑定、if constexpr、求值顺序部分明确化C20概念、协程、范围库、模块起步C23进一步打磨标准库完善异步与格式化能力这张表不是让你背版本号而是想说明C 不是静态语言它一直在“自增”。你今天写的代码很可能会在下一代标准下获得新语义反过来老代码也可能在新标准下暴露出原来没被察觉的问题。把语言本身当作一个会自增的对象能帮你建立一种更动态的认知。6.3 我从这个双关里养成的习惯说句实在话写了很多年 C 后我再看到“C 和 c”这个标题第一反应已经不是语法题了而是一种提醒符号所在位置决定语义而语义背后又牵连着历史与标准。语言名里的“”是后置推荐写法里的“c”是前置一个代表继承与演进一个代表效率与明确取值。搞懂这两件事比单纯记住哪条指令更快更有价值。日常编码时我依然保持着那个简单到近乎枯燥的习惯默认c旧值需求才c。这个习惯从语法到语义都稳稳当当也是我从这个自带双关的标题里真正带走的东西。
“C 和 c”这两个词放在一起乍一看像程序员之间才懂的冷笑话。但如果你真在代码里和它们长期打交道会发现这个标题里藏着的是一语三关C 是一门语言名字c 是一个具体的自增表达式而把“C”这个单词重新拆开时它自己也是一个“后缀递增操作符”的变体。很多人刚接触时会把语言名和运算符混在一起甚至在面试、笔试里被“c 和 c 有什么区别”这种题绕晕。这篇不是我打算从语法表上抄一段标准答案就想按一个从业者的理解把二者背后的历史、语义、性能和坑都摊开讲一讲。适合读这篇的不只是正在学 C 的初学者也包括写了几年 C 但未必深究过前缀自增细节的人。标题里这个“c”看着简单但它牵扯到值类别、求值顺序、运算符重载、未定义行为甚至能延伸到语言标准演进。读完之后你再看“C”三个字母感觉会完全不一样。1. 语言名里的彩蛋为什么叫 C以及 c 的第一次相遇1.1 C 的名字本身就是一次运算C 的前身叫“带类的 C”改名成 C 是在 1983 年前后。当时参与语言设计的一位开发者喜欢开玩笑借用了 C 语言里的自增运算符“”把名字写成“C 的自增”意思是“在 C 的基础上向前走一步”。这个命名很有幽默感也很有信息量它用一个运算符描述了语言和前辈的关系而不是另起炉灶造一个抽象词。有意思的是名字里的“”是放在 C 后面的严格说是“后缀自增”。如果按运算符语义来理解c表达式的值是“自增前的旧值”副作用是“让 c 本身加一”只不过这个“加一”发生在后续某个求值时间点。把这种语义映射到语言上会得到一种很妙的解释你先拿到的是老 C 语言副作用是得到一门增强了的新语言。也就是说C 这个名字天然地带着“从旧到新、从 C 到 C”的时间感。那你再看标题里的c它是前缀自增正好反过来先执行副作用把变量加一之后再取新值。当年取名字的人多半没想过要和运算符语义严格对齐但这两者的差异恰好构成一个有趣的对照——C 这个名字选中了“后置”而普通代码里我们写的c是“前置”。一个是语言命名一个是日常操作符号相同解读不同就这么凑在了一起。1.2 当我们写下 c 时写的到底是什么在代码层面c是一个表达式含义是对变量 c 执行自增副作用然后让整个表达式的值是自增后的新值。比如int c 10; int n c;执行完之后 c 变成 11n 也变成 11。很多人第一次接触时容易把它读成“c 加加”然后误以为c就是“C 语言”。其实语言名 C 不是一个表达式它只是长得像表达式而c是真会修改内存里数据的操作。从符号学角度这三层关系很清楚C是语言标识符c是运算符表达式C则可能是变量名、类型名或语言名字。同一个“”在不同位置、不同语境里扮演着完全不同角色。这种多义性正是 C/C 体系里常见的一种“令人头疼又令人兴奋”的特性。1.3 三种层次的读者三种理解方式我见过完全不写代码的人看到“C 和 c”只会觉得是乱码也见过学 Python 出身的初学者把 C 当成“某种高级语言”把 c 当成“一个奇怪的写法”而真正写 C 的老手看到这个标题第一反应是“前缀和后缀的区别”第二反应是“语言为什么叫 C”第三反应才会去看题目里有没有陷阱。这种层次感本身很有价值。它提醒我们很多基础概念不需要死记硬背从名字和符号的来龙去脉去理解反而记得更牢。接下来的内容我会把c这个“表达式”彻底拆开再把“为什么推荐在代码里多用c”这件事讲明白。2. c 的执行细节前置自增不是换个位置那么简单2.1 五个必须记住的语义点要真正掌握c下面这几点缺一不可自增副作用发生在“读取表达式结果”之前。整个表达式的值是自增后的新值。对内置类型来说表达式结果在 C11 之后是左值。操作数必须是一个可修改的左值不能写5这种明显无效的表达式。它等价于c 1而c等价于(c 1) - 1这种取旧值的过程。第一点和第三点是重中之重。比如下面这段代码int c 7; int* p (c); // 合法c 是左值可以取地址 int* q (c); // 不合法c 的结果是右值第二行能编译第三行会报错。报错信息通常是“无法将右值绑定到指针”之类。这个区别在日常业务代码里未必常见但在泛型编程、模板元编程里它是判断某个表达式能不能被安全引用的关键。2.2 前置和后置的直观差异如果用一句话概括c是“我先给你加好再把新值拿给你”c是“我先把旧值拿给你回头我再自己加”。对应到实际使用c适合你根本不在乎旧值的场景比如循环步进、迭代器前进、计数器累加。c适合你需要“操作前的状态”的场景比如v[i] x想把 x 写到下标 i 处同时让 i 自增。看这段代码就更直观int i 0; int a i; // a1, i1 int b i; // b1, i2a 和 b 虽然同样是 1但背后的时序完全不同。正因为i需要先保留旧值在类类型昂贵时它会比i多一次拷贝这在标准库迭代器里体现得很明显。2.3 为什么 c 的结果可以是左值C11 之前内置类型的前缀自增结果是不是左值标准里没那么明确很多老书也写得含糊。C11 正式规定c的结果是左值c的结果是右值。这一改变让泛型代码里可以统一通过x拿到可写引用也让连续自增成为可能。看下面这个写法int c 0; c; // 合法先 c 得到左值再对左值 最终 c2但你不能写c。因为c的结果是右值右值不能再做非成员自增。这个例子特别适合用来检验自己是不是真懂了左值右值而不是只会在面试题里背概念。3. 性能与习惯为什么代码规范总推荐 c3.1 内置类型没有肉眼可见的性能差很多人一开始会纠结c真的比c快吗对 int、double 这类内置类型答案是在现代优化编译器里单条语句的c和c生成的机器码几乎完全一样。你可以分别写这两行再反汇编看看int c 0; c; c;在没有开优化时两条语句可能都对应一个inc指令开了优化后如果结果没被使用编译器甚至直接把两条都优化掉。对内置类型性能不该成为你选前置还是后置的理由真正的理由在语义一致性。3.2 迭代器和类类型的差别才是关键一旦操作对象是迭代器、智能指针、或者任何定义了自增运算符的类类型后置自增就会暴露它笨重的一面。因为标准语义要求c返回“自增前的旧值”很多实现必须临时构造一个副本再对原对象做自增最后返回那个临时副本。想象一个链表迭代器内部保存着当前节点指针。如果v.end()这种迭代器本身只是单个指针拷贝成本不高但如果是一个内部持有多个成员、或者带有共享资源管理的迭代器每次c就可能触发一次拷贝构造甚至一次引用计数增减。我自己写泛型循环时长期坚持一个习惯遍历时不用it统一写it。这不是教条是为了让代码在不同容器、不同迭代器实现下都能获得稳定的行为。你不会知道哪天别人会把你的vector迭代器换成一个自定义的代理迭代器那时每个it都会实打实多一笔开销。3.3 从老规矩到新习惯你可能在旧代码里见过这种风格for (std::vectorint::iterator it vec.begin(); it ! vec.end(); it)这段在单线程里运行没问题但如果被 code review 较真大概率会被建议改成it。现代 C 里range-based for 已经帮我们屏蔽掉了大量手写迭代器循环但在算法库自定义迭代器、或者底层容器实现里你仍然躲不开自增运算符的选择。推荐的规则其实很简单默认使用c只有在“确实需要旧值”时才使用c。把这条规则当成肌肉记忆比任何性能测试都可靠。4. 运算符重载亲手实现一个 c 的正确姿势4.1 前缀和后缀的不同签名如果你想给自己写的类支持自增你需要同时实现两个版本。语法上后缀版本必须带一个 int 占位参数这是 C 为了区分两者而设计的“语言技巧”class Counter { public: explicit Counter(int v) : value(v) {} Counter operator(); // 前置 c Counter operator(int); // 后缀 c private: int value; };这个 int 参数只是用来区别签名不会真的传值进去所以你通常不会给它命名编译器也不在乎。调用时c选前置版本c选后缀版本。4.2 推荐的实现模板后缀复用前缀正确的做法不是把两份逻辑各写一遍而是让后缀版本调用前缀版本。标准做法长这样Counter Counter::operator() { value; return *this; } Counter Counter::operator(int) { Counter old *this; // 保存旧值 (*this); // 复用前置实现 return old; // 返回旧值 }这种写法的好处很明显真正修改状态的逻辑只出现在前置版本里后缀版本只负责“先拷贝再复用后返回”。这样万一以后字段变了、逻辑复杂了你只需要改一个地方两个版本的行为都会保持一致。返回值类型也不能搞错前置返回Counter允许链式修改后缀返回Counter因为它代表的旧对象本就是临时的返回引用会变成悬空引用那是未定义行为。4.3 链式自增和它的边界前置版本返回引用所以你可以写counter连续两次自增最终状态正确。后缀版本返回临时对象所以counter编译不过或者说即使编译器允许它自增的也只是一个临时对象的副本原对象根本没变。这个差异平时很少有人利用但如果你在设计一套数值类型或迭代器接口它其实是一个值得暴露给调用方的语义特征。你不仅是在重载运算符你是在决定“这个类型允许被怎样连续操作”。5. 最容易踩的坑c 相关的未定义行为与求值顺序5.1 一个表达式里别写两次同类自增C 和 C 的老开发者都听过一句话“同一个变量在一个表达式里被多次修改行为未定义。” 这句警告放在c身上再合适不过。int i 1; i i i; // 未定义行为不要问结果是多少这样的代码在标准里就是“未定义行为”编译器可以做任何事它可能算出 4可能算出 5可能在调试版里崩掉也可能在优化后直接返回一个你根本想不到的值。原因在于同一个变量 i 在一个完整表达式里被多次写而 C 没有规定这些副作用的发生顺序编译器可以自由选择生成指令的顺序和方式。5.2 C17 修正了什么又没修正什么C17 之后标准对很多运算符的求值顺序做出了明确要求比如a.b中先求 a函数调用中实参的求值顺序不再完全任意。但千万别以为 C17 把所有旧坑都填了。下面这些写法在 C17 之后的正式标准里依然是未定义行为foo(i, i); // 两个参数的求值顺序互相未规定副作用交叉 arr[i] i; // 下标和赋值目标都修改 i互相未规定 i i; // 同一个变量读改写混在一起这些代码在今天的编译器里也可能会“碰巧”给出结果但碰巧不等于合法。只要换了编译器版本、优化选项或者周围的表达式结构结果就可能变。安全边界其实非常简单一个完整表达式里同一个变量最多被写一次如果确实要连续改拆成多条语句。5.3 现场排查实录while 循环里的前缀陷阱我在实际项目里排查过一个挺有代表性的问题。某跨平台系统的日志模块里有一段循环int index 0; while (index count) { // 处理 index }新来的同事觉得index和index应该没区别改成while (index count)。结果第一条日志被跳过了边界条件也整体偏移。排查了大半天最后发现就是这个前置和后置的语义差异——前置是先自增再比较后置是先比较再自增。这个案例给我留下的教训不是“不要改代码”而是“读循环条件时先看清楚自增位置”。很多人写代码时顺手用i但在判断条件里它和i是完全不同的逻辑。这也是面试官特别喜欢考while (i)和while (i)的原因。6. 把语言名当成运算符C 自身也是一次自增6.1 标准版本一次一次地“前置自增”C 语言本身从 C98 到 C11再到 C14、C17、C20、C23每一次新标准都像是对这门语言做了一次自增操作。新特性落地并不是“下个版本才有”而是在标准发布那一刻起就成为一种新状态。如果沿用这个比喻语言演进更像c先让标准生效之后你写代码时拿到的就是新语言。C 这个名字里的“”是后缀看起来像c严格说是旧 C 之后才增强。但实际体验中每当我切换到新标准感觉更像是“前置自增”——新标准先被应用然后所有代码都在新的状态下编译运行。这个反差挺有趣也常被用来解释为什么 C 的兼容性包袱那么重你不能像c那样把语言推到新状态后就完全丢掉旧值因为太多老代码依赖那个“旧值”。6.2 标准版本速览版本主要变化C98第一个正式标准模板、STL 基础成型C11移动语义、右值引用、lambda、auto现代 C 真正的起点C14泛型 lambda、返回类型推导增强C17结构化绑定、if constexpr、求值顺序部分明确化C20概念、协程、范围库、模块起步C23进一步打磨标准库完善异步与格式化能力这张表不是让你背版本号而是想说明C 不是静态语言它一直在“自增”。你今天写的代码很可能会在下一代标准下获得新语义反过来老代码也可能在新标准下暴露出原来没被察觉的问题。把语言本身当作一个会自增的对象能帮你建立一种更动态的认知。6.3 我从这个双关里养成的习惯说句实在话写了很多年 C 后我再看到“C 和 c”这个标题第一反应已经不是语法题了而是一种提醒符号所在位置决定语义而语义背后又牵连着历史与标准。语言名里的“”是后置推荐写法里的“c”是前置一个代表继承与演进一个代表效率与明确取值。搞懂这两件事比单纯记住哪条指令更快更有价值。日常编码时我依然保持着那个简单到近乎枯燥的习惯默认c旧值需求才c。这个习惯从语法到语义都稳稳当当也是我从这个自带双关的标题里真正带走的东西。
