C++代码简化之道

1. 善用emplace

C++11开始STL容器出现了emplace（置入）的语义。比如 vector、map、unordered_map，甚至 stack和 queue都有。

emplace方便之处在于，可以用函数参数自动构造对象，而不是向vector的push_back，map的insert那样传入一个构造好的对象。

举个例子，比如有这么一个对象。

  1. class Point {
  2. public:
  3.     Point(int x, int y):_x(x),_y(y){}
  4. private:
  5.     int _x;
  6.     int _y;
  7. };

C++11之前。大概的写法

  1. std::vector<Point> vp;
  2. std::map<std::string, Point> mp;
  4. Point p(1, 2);
  5. vp.push_back(p);
  6. vp.push_back(Pointer(3, 4));
  8. Point p1(10, 20);
  9. mp.insert(std::pair<std::string, Point>("key1", p1));
  10. Point p2(100, 200);
  11. mp.insert(std::make_pair("key2", p2));

C++11之后：

  1. std::vector<Point> vp;
  2. std::map<std::string, Point> mp;
  4. vp.emplace_back(1, 2);
  5. vp.emplace_back(3, 4);
  7. Point p1(10, 20);
  8. Point p2(100, 200);
  9. mp.emplace("key1", p1);
  10. mp.emplace("key2", p2);

注意，其实也不需要无脑使用emplace_back。比如，当你的使用场景中，已经确切存在了一个Point的对象，你需要把它放进vector：

  1. // 彼时，你已经有了一个Point的对象p。不需要自己凭空构造。
  2. vp.push_back(p);
  3. vp.emplace_back(p);

这种情况下，两种写法的表现几乎无差别（push_back反而短……当然可能也没必要追求这个）。见过一些老项目> 升级C++11之后，无脑给push_back全替换成emplace_back的。虽然也没啥问题，但其实有时候没必要。

当然，当需要从参数来构造出对象的时候。那么 emplace_back明显会简洁许多。但此时push_back其实除了代码冗长外，其性能开销也没有比emplace_back高太多，因为

  1. vp.push_back(Pointer(3, 4));

调用的是：

  1. void push_back (value_type&& val);

有较真的网友提到 emplace的置入功能，还是要比这种push_back (value_type&& val)稍胜一筹，anyway。两个函数实现逻辑不同，肯定无法做到性能完全一致，但是也没到足以影响自己编码习惯的地步。总而言之当要放入 vector的对象不存在的时候，直接用 emplace_back来构造，在已存在的时候用 emplace_back或 push_back都可以。

2. 在不影响可读性的情况下使用auto，区分auto& 、auto&&

auto不多解释了。

很多C程序员被问『熟悉C11吗？说一说』

答一个『auto』

没啦

auto就是用来简化长类型的（比如命名空间嵌套曾经很深）。另外auto&和auto&&(万能引用）也不多解释了。

当然滥用auto也会造成代码可读性变差。在我等不用IDE，用vim开发C++的程序员面前，auto滥用犹如噩梦。没有>类型提示啊。

3. lambda表达式替换手写函数和函数对象

lambda表达式（或者说lamba对象）可能是C程序员在回答『熟悉C11吗？』这个问题，答完auto之后，说出的第二个新语法。

有了lambda，STL的algorithm里的函数，用起来更简洁了。

另外lambda除了替代了定义普通函数、函数对象（重载operator()）之外，还有其他便利。那就是闭包的特性。说闭包可能一时难以理解。你就可以理解成是lambda的引用捕获功能。

在lambda的参数之外，获取到了其他的参数。并且是可跨越lambda生命周期的。

唯一需要注意的是：引用捕获可能在后续lambda对象被实际调用的时候，出现引用悬空（类似空指针），从而出现core dump。

4. 给冗长的类型建立别名，尤其是std::function类型

看一段冗长的代码。

  1. class FuncFactory {
  2. public:
  3.     void put_func(std::string, std::function<std::vector<std::string>(std::string)>);
  4.     std::function<std::vector<std::string>(std::string)> get_func(std::string);
  5. private:
  6.     std::unordered_map<std::string, std::function<std::vector<std::string>(std::string)>> _func_map;
  7. };

用using简化掉：

  1. using func_t = std::function<std::vector<std::string>(std::string)>;
  3. class FuncFactory {
  4. public:
  5.     void put_func(std::string, func_t);
  6.     func_t get_func(std::string);
  7. private:
  8.     std::unordered_map<std::string, func_t> _func_map;
  9. };

5. 头文件中使用#pragma once替换老破旧#ifndef #define #endif

从上个世纪70年代C语言诞生之始，头文件都在使用#ifndef #define #endif来避免重复包含。

  1. #ifndef HEADER_FILE
  2. #define HEADER_FILE
  4. ...
  5. #endif

C++也继承了这种写法。然而时至今日还可以这样写：

  1. #pragma once
  2. ...

这个语法很久之前就有，但并非是C标准的一部分。但在很多编译器厂商的实现中，早早地支持了这种语法。C11中这个语法依旧没有转正，但是由于被编译器广泛支持，几乎可以放心使用了。在Google和Facebook的C++开源项目中都有大量使用。#ifndef #define #endif终于寿终正寝。

当然在个别情况下，这个语法也存在坑：

不同于头文件防护，这条语用使得错误地在多个文件中使用相同的宏名变得不可能。另一方面，因为带#pragma once的文件是基于其文件系统层次的身份所排除的，所以若头文件在项目中有多个位置，则这不能防止包含它两次。

可以参考：https://zh.cppreference.com/w/cpp/preprocessor/impl

简而言之，pragma是基于头文件的文件路径来保持唯一的。而宏可以做到跨多个文件来保持include的唯一性。比如当你一个代码库中存在一个头文件的多个版本……

一般情况下，我们可能很少在一个项目中需要用到一个头文件的多个版本，反正我是没这种需求。

6. 善用for range遍历容器，也可以针对PB的repeated字段（甚至mutable）

还在用下标遍历容器吗？

  1. for (int i = 0; i < v.size(); ++i) {
  2.     cout<<v[i]<<endl;
  3.     v[i] *= 10;
  4. }

java和其他语言早有不借助下标的for - range循环，C++11也有了：

  1. for (auto& e: v) {
  2.     cout<<e<<endl;
  3.     e *= 10;
  4. }

最好用引用&来遍历，否则如果容器中存储的是对象，会出现拷贝。当然如果你不想修改容器内元素的话，也可以用const auto& 遍历。

C++工程项目中，protobuf肯定是会大量使用的。for range也可以遍历pb的repeated字段

  1. syntax = "proto3";
  2. message Student {
  3.     string name = 1;
  4.     int32 score = 2;
  5. }
  6. message Report {
  7.     repeated Student student = 1；
  8. }

代码中：

  1. // report 是一个Report类型的对象
  2. for (auto& student: report.student()) {
  3.     cout<< student.name << "'s score:" << student.score << endl;
  4. }

工作中看多很多遍历pb repeated字段代码大多可以做到上面那样。但是当遍历pb repeated字段并修改其中变量的时候（mutable返回的是指针，不能直接for range），很多人还是选择了用传统的for+下标的形式来遍历。其实不用，依旧可以for range

  1. for (int i = 0; i < report.student_size(); ++i) {
  2.     report.mutable_student(i)->set_score(60); // 60分万岁！
  3. }

啰嗦！！！！！！！！！！！可以这样写：

  1. for (auot& student: *report.mutable_student()) {
  2.     student.set_score(60);  // 60分万岁！
  3. }

7. 用do while或IIFE跳过部分连续逻辑，但不结束函数

你有没有这种体验：在函数中一段平铺的逻辑中，依次经历1，2，3三个步骤，然后是其他逻辑（比如 4，5）。其中1，如果失败就不执行2，2如果失败不执行3。就是逻辑中断之后直接跳到4和5。容易想到的实现思路有三：

其一：把步骤1，2，3抽象成函数。每次判断函数的返回值，成功才调用下一个函数。OK。这样没问题。但是如果顺序逻辑太多。那么要抽成很多个函数，而且每个函数内只有寥寥几行代码。反而啰嗦。

其二：使用异常。如果是Java语言应该很习惯用异常来实现这个逻辑，把顺序逻辑封在 try catch块里。每个步骤失败直接throw异常。OK，C也可以写类似的代码。然而C用异常隐患很多，不如Java安全，很多工程规范都竭力避免抛异常。另外就是抛异常也不是无开销的，而且这里只是逻辑中断，逻辑上也不算『异常』，通过throw异常和catch异常的方式未免更加影响表现力……

其三：goto。看过一些代码确实在这种场合使用过goto。当然我们要严厉禁止goto。这个方案直接略过。

其实还有第4种方案：do while(0)

  1. do {
  2.     // 步骤1
  3.     ...
  4.     if (步骤1失败) {
  5.         break;
  6.     }
  7.     // 步骤2
  8.     ...
  9.     if (步骤2失败) {
  10.         break;
  11.     }
  12.     // 步骤3
  13.     ...
  14.     if (步骤3失败) {
  15.         break;
  16.     }
  17. } while(0);
  19. // 步骤4
  20. ...
  21. // 步骤5
  22. ...

这个其实也适用于其他有do while的语言，不止C++。另外由于C++11中lambda函数的出现，你还可以这样写：

  1. []() {
  2.     // 步骤1
  3.     ...
  4.     if (步骤1失败) {
  5.         return;
  6.     }
  7.     // 步骤2
  8.     ...
  9.     if (步骤2失败) {
  10.         return;
  11.     }
  12.     // 步骤3
  13.     ...
  14.     if (步骤3失败) {
  15.         return;
  16.     }
  17. }();
  19. // 步骤4
  20. ...
  21. // 步骤5
  22. ...

这个是在普通 lambda表达式的末尾加上了一个括号，也就是让定义的lambda可以立即执行。

这一特性也被人称为IIFE（Immediately Invoked Function Expression），即立即调用函数表达式。这是一个出自 Javascript的术语，可能不是C++中的正统称呼……

8. 某些情况下用struct替代class，避免把C++类写成JavaBean

因为种种原因，从Java转C的程序员，喜欢把C的类写成JavaBean。动不动就set()、get()

当然这种封装也没问题，数据成员设置成private，所有的访问都通过接口函数。只是太教条的话，反而啰嗦。C++中，我喜欢把纯数据类型（只含数据）的类，直接用struct来表示。不包含任何成员函数。也不需要要用class，然后设置一个public。就用struct更直观！

【当然，这条可能有争议~】

9. 函数直接返回STL容器或对象。不要返回指针，也不需要给函数加出参

C++11之前。如果要返回一个STL容器（或其他复杂类型）的对象怎么办?

第一种：

  1. void split(std::string str, std:string del, std::vector<std::string>& str_list) {
  2.    // 解析字符串str，按del分隔符分割，拆成小字符串存入str_list中
  3.    ...
  4. }
  6. // 调用方：
  7. std::vector<std::string> str_list;
  8. split("a:b:c:d", ":", str_list);

这种用的时候不太方便。如果不是split，而且其他例子。我可能想一行连续点点点调用返回值的成员变量（foo().bar().xxx()）。无疑，上面这种会中断我的一行语句写法。

第二种：

  1. std::shard_ptr<std::vector<string>> split(std::string str, std:string del) {
  2.     std::shard_ptr<std::vector<string>> p_str_list = std::make_shared<std::vector<std::string>>();
  3.     // 解析字符串str，按del分隔符分割，拆成小字符串存入p_str_list中
  4.     ...
  5.     return p_str_list;
  6. }

或者最原始版本:

  1. std::vector<std::string>* split(std::string str, std:string del) {
  2.     std::vector<std::string>* p_str_list = new std::vector<std::string>;
  3.     // 解析字符串str，按del分隔符分割，拆成小字符串存入p_str_list中
  4.     ...
  5.     return p_str_list;
  6. }
  1.    <br />需要小心的处理返回值，自己控制delete掉指针，避免内存泄露。

都太啰嗦。但无一例外。熟悉C98的老前辈们都不会建议你用函数直接返回STL容器。然而事情从C11开始起了变化。那些不熟悉C++98的新手程序员们反而写出来最优解：

  1. std::vector<std::string> split(std::string str, std:string del) {
  2.     std::vector<std::string> str_list;
  3.     // ...
  4.     return str_list;
  5. }

相信我，没问题。

这个变化，其实也在工作中造成一些尴尬。有时候我写这种代码，在给老同事过core review的时候，生怕被批一顿代码写的烂。如果被批一顿，我自然尴尬，然后我解释一番这种写法在C++11里面没问题，那么老同事就尴尬了。

为避免这种尴尬我总会在代码附近加个注释:

  1. // it's ok in C++11
  2. std::vector<std::string> split(std::string str, std:string del);

其实C11之前也有这么用的。因为编译器自己做的RVO，NRVO优化，这当然是非标的。改一下编译选项可能就没啦。虽然gcc不显式关闭RVO的话，默认就开始的。但曾经我在C98的环境下工作时，还是很少见到这种直接返回对象的写法。其实不是所有返回对象函数定义都能触发RVO，如果不清楚，C++98的程序员还是谨慎使用。

但是C++11开始，你不用担心了。

10. 利用unordered_map/map的[]运算符的默认行为

比如我们程序中有一个计数逻辑，使用了一个 unordered_map（或map)来对某个 string类型的tag进行计数。之前看到有同事这样写：

  1. // freq_map 是一个 unordered_map<string, int> 类型。
  2. // 通过某个计算获取到了一个string类型的变量tag，下面进行计数
  3. if (freq_map.find(tag) == freq_map.end()) {
  4.     frea_map.emplace(tag, 1);
  5. } else {
  6.     freq_map[tag] += 1;
  7. }
  9. // 或者这种
  10. if (freq_map.find(tag) == freq_map.end()) {
  11.     frea_map.emplace(tag, 0);
  12. }
  13. freq_map[tag] += 1;

其实通通不用，上述两种大概是python中用dict来计数的写法（当年我写MapReduce任务的时候也有类似的写法）但是C不用，因为。C的map在使用 [] 运算符的时候会在key不存在的时候默认创建出一个值！如果value是基本数据类型，那么就是0。

所以可以直接写：

  1. frep_map[tag]++;
  2. // 或
  3. freq_map[tag] += 1;

当然也正因为 [] 运算符的这个默认性质所以 Effective C里面才有一条说要用m.insert()来插入key，value(C11之后用emplace)而不要用m[key] = value的写法，因为后者会先构造一个空对象，再覆盖掉它。当然具体到我这里提到这个计数场景，不需要考虑这个。因为本来就需要在key不存在的时候初始化一个，而且value是基本数据类型，初始化成0，然后覆盖成1，开销不大。