共计 2452 个字符，预计需要花费 7 分钟才能阅读完成。
读了《C++ 的门门道道 | 技术头条》这篇文章之后有很多共鸣，可以说是近期看过的最好的技术 tips 文章了。按照这篇文章里面讲到的几点，结合工作上实际遇到的问题，我也来说一下我的感受。
<!– more –>
成员变量初始化
成员变量忘了初始化是一个相当经典的错误，甚至《Effective C++》中还专门列了一条来讲这个事情。在工作中，我就看到过这种错误，同事对一个新增的功能加上了开关控制的逻辑，但是忘了对这个开关的标识进行初始化，导致了一条分支逻辑失效。而且因为 C++ 没有默认初始值，那它的初始值是随机的，所以导致线上的表现是概率性复现，增加了 debug 的难度。当然增加 Coverity 扫描提早发现这个问题，当时项目上线比较急就直接跳过了这一步。
从 C++11 开始支持在声明成员变量的时候直接初始化，有了这个特性之后，我已经养成了所有成员变量都直接在声明的时候初始化。
class Ad {
private:
unsinged int lifetime = 10000;
};
sort() 里的坑
这个坑即便是有点经验的程序员也会踩到，有一次线上事故就是一个稳定跑了很久的逻辑，突然出现了 core，而且是持续地 core 在 sort 上。花了很长时间排查，最后才意识到实现新增的 sort 比较函数没有保证严格弱序（strict weak order），比较两个对象的属性时用了 <=。这里就涉及到 C++ 中 sort 的实现。细节之后会写一篇文章来讲，简单说来就是 STL sort 核心排序算法是快排，在依据 pivot 调整元素位置时采用的实现方式如下：
while (true)
{
while (__comp(*__first, __pivot))
++__first;
–__last;
while (__comp(__pivot, *__last))
–__last;
if (!(__first < __last))
return __first;
std::iter_swap(__first, __last);
++__first;
}
重点就在于 while (__comp(*__first, __pivot)) ++__first;，当整个容器里的元素都相等时，就会导致 __first 这个迭代器越界，程序就 core 了。
操作符短路
原文关于如何避免操作符短路讲得很好了，其实我们还可以利用操作符短路来简化代码。对我更常用的场景：if (!stack.empty() && stack.top() == 0)，这恰恰是利用短路来合并判断。
别让循环停不下来
这个有个经典场景，在 vector 里面，我要找到首个递增序列的最后一个元素，很容易写成这样的代码：
while (i < ve.size() – 1 && ve[i] <= ve[i + 1]) i++;
这里如果传入的 ve 是个空 vector，那么就会成为超大循环，因为 vector::size() 返回的是 unsigned int，根据数值类型传递，ve.size() – 1 的类型也是 unsigned int，那么就会返回一个很大的数，导致 while 陷入超大循环。
理解 vector 的实现
vector 可以说是在日常开发中使用频率最高的容器了，支持下标访问，动态扩容，二分查找的效率，C++11 之后支持移动构造，这些优点都让它非常好用。vector 的坑都集中在它的动态扩容上，理解它动态扩容的机制可以在开发中避开这些坑。
vector 动态扩容的两个特点：
vector 扩容是按照 2 的指数倍往上翻的，也就是 2, 4, 8, 64, 128, ……。
动态扩容时是会全量复制一遍现有的所有元素到新分配的内存中。
根据这两个特点，结合 vector 的其他特性得到的：
尽量预先分配好 vector 的空间，使用 reserve() 预分配空间，避免多次扩容。
不要在 vector 里存储大对象，扩容的时候会全量复制，额外的性能开销很大。
不要保存指向 vector 内部对象的指针，扩容时对象地址会发生变化。
reserve() 是提前分配空间，此时不能直接用下标索引访问（如果用基本类型倒是能访问，但是这种行为仍然是未定义的）。
有时候真的不必用 std::unorder_map
组里有一个项目升级到 C++11 之后，一窝蜂地使用 unordered_map，但是其实对于小数据量，比如本次请求命中的一些配置，其实数据量基本都在 10 项以内，那其实用 map 就完全够用了，unorder_map 查找的效率当然是高的，但是也要认识到它维护一个哈希表额外付出的性能代价。
慎用 short，char
因为一开始设计的数值类型过于严格而导致的重写，我遇到过不止一次了。
有些人写代码的时候有一种倾向，就是能省则省，能用 int 的绝不用 long，能用 short 的绝不用 int。但是其实有些情况下 short 并不能节省空间（字节对齐），还导致过度「优化」，导致逻辑变化之后要重写，或者实际的取值不符合设计导致溢出。
避免箭头型代码
什么是「箭头型代码」？见下图：
这种代码其实在业务复杂的场景下并不少见，酷壳上有一篇文件专门讲过如何重构这种代码：《如何重构“箭头型”代码》。
我在实际项目中应用比较多是利用 while (0) 来规避这种代码。
在项目经常遇到的场景是对一连串条件进行判断，不符合条件的分支需要打印日志，示例代码如下：
if (conditionA()) {
if (conditionB()) {
if (conditionC()) {
if (conditionD()) {
// do something
} else {
// log
}
} else {
// log
}
} else {
// log
}
} else {
// log
}
这种情况下用 do-while(0) 可以进行非常好的重构，重构之后的代码如下：
do {
if (!conditionA()) {
// log
break;
}
if (!conditionB()) {
// log
break;
}
if (!conditionC()) {
// log
break;
}
if (!conditionD()) {
// log
break;
}
} while (0);
参考文章：
《C++ 的门门道道 | 技术头条》
《STL 源码剖析》
