18、循环控制：for循环中i++与++i的效率差异
这个问题，说实话，是C语言面试里特别爱考的一道题。很多新手觉得「不就是个自增嘛，能有多大区别？」。嗯，我当年刚入行时也这么想，直到有一次在嵌入式项目里被狠狠上了一课。
先直接说结论：在绝大多数现代编译器中，对于基本类型（int、char等），i++和++i生成的机器码是一样的。但事情没这么简单，咱们得把场景拆开看。
基本类型：编译器帮你擦了屁股
对于int、short、char这些基础类型，你写i++还是++i，编译器优化后基本没差别。我特意在ARM Cortex-M4和x86-64两个平台上做过测试，开了-O2优化后，生成的汇编指令完全一致。
// 这两种写法，编译器优化后没区别
for (int i = 0; i < 100; i++) {
// do something
}
for (int i = 0; i < 100; ++i) {
// do something
}为什么会这样？因为编译器知道i是基本类型，i++需要「先保存旧值，再自增，返回旧值」这个语义，但编译器发现旧值根本没人用，就直接优化成「自增」一条指令了。
自定义类型：差距就出来了
这里才是真正的陷阱。当你用C++的迭代器或者自定义类时，++i和i++的效率差距就非常明显了。
你想想看，后置自增（i++）需要返回自增前的值，那就得先拷贝一份旧值。对于复杂的迭代器对象，这个拷贝操作可能涉及内存分配、深拷贝，开销不小。而前置自增（++i）直接返回自增后的引用，省去了拷贝。
// 假设有个自定义迭代器
class MyIterator {
// ... 内部有复杂数据结构
};
// 这种写法，每次循环都产生一次临时对象拷贝
for (MyIterator it = begin; it != end; it++) {
// ...
}
// 这种写法，没有临时对象，效率更高
for (MyIterator it = begin; it != end; ++it) {
// ...
}我在项目中遇到过这样一个案例：一个图像处理算法，循环里用了STL容器的迭代器，写的是it++。数据量小的时候没问题，后来图像分辨率从640×480升级到4000×3000，程序直接跑不动了。查了半天，发现就是后置自增导致的临时对象拷贝，每次循环多拷贝了一个迭代器对象。改成++it后，性能提升了将近30%。
嵌入式场景的特殊性
做嵌入式开发，咱们经常要面对资源受限的MCU。有些低端MCU的编译器优化能力有限，甚至有些场景下不能开优化（比如调试阶段）。这时候，i++和++i的差异就真的能体现在指令数上。
| 场景 | i++ 指令数 | ++i 指令数 | 说明 |
|---|---|---|---|
| 基本类型，开优化 | 1条 | 1条 | 编译器优化后无差异 |
| 基本类型，不开优化 | 3条 | 2条 | i++多了一条保存旧值的指令 |
| 自定义类型，不开优化 | 5~10条 | 2~3条 | 差距主要来自拷贝构造 |
说白了，如果你在写裸机程序，或者用着比较老的编译器，养成用++i的习惯确实能省几条指令。虽然单次循环省的不多，但循环几万次、几十万次，积少成多。
知识体系梳理
我把这个问题的核心逻辑画了张图，方便你理解：
总结一下
- 基本类型（int、char、指针等）：在开优化的情况下，i++和++i没区别。不开优化时，++i略优。
- 自定义类型（迭代器、类对象等）：永远用++i。这是C++社区公认的最佳实践。
- 嵌入式特殊场景：如果你在写资源极度受限的MCU程序，或者编译器比较老，建议统一用++i，养成习惯不吃亏。
我的个人建议：写C代码时，我习惯用i++，因为可读性更好，而且编译器会帮我优化。但一旦涉及C++迭代器，我会立刻切换成++i。说白了，知道原理，根据场景做选择，这才是工程师该有的态度。
嗯，关于i++和++i的效率问题，就聊到这儿。记住一点：不要盲目相信「++i一定比i++快」这种一刀切的结论，也别完全无视它。理解背后的原理，你才能在写代码时做出正确的选择。