我是极简主义者，崇尚简洁明快的代码风格，这也可能是我不喜欢Java全家桶的原因……当然我说的简洁是要建立在不降低可读性的前提下，即不影响代码本身的表现力。如果为求代码精简而让代码晦涩艰深同样不可取。
本文会介绍10个条款，后续还会陆续更新相关的内容，请大家持续关注！
C++11开始STL容器出现了emplace（置入）的语义。比如 vector、map、unordered_map，甚至 stack和 queue都有。
emplace方便之处在于，可以用函数参数自动构造对象，而不是向vector的push_back，map的insert那样传入一个构造好的对象。
举个例子，比如有这么一个对象。
class Point {
public:
Point(int x, int y):_x(x),_y(y){}
private:
int _x;
int _y;
};
C++11之前。大概的写法
std::vector<Point> vp;
std::map<std::string, Point> mp;
Point p(1, 2);
vp.push_back(p);
vp.push_back(Pointer(3, 4));
Point p1(10, 20);
mp.insert(std::pair<std::string, Point>("key1", p1));
Point p2(100, 200);
mp.insert(std::make_pair("key2", p2));
C++11之后：
std::vector<Point> vp;
std::map<std::string, Point> mp;
vp.emplace_back(1, 2);
vp.emplace_back(3, 4);
Point p1(10, 20);
Point p2(100, 200);
mp.emplace("key1", p1);
mp.emplace("key2", p2);
注意，其实也不需要无脑使用emplace_back。比如，当你的使用场景中，已经确切存在了一个Point的对象，你需要把它放进vector：
// 彼时，你已经有了一个Point的对象p。不需要自己凭空构造。
vp.push_back(p);
vp.emplace_back(p);这种情况下，两种写法的表现几乎无差别（push_back反而短……当然可能也没必要追求这个）。见过一些老项目升级C++11之后，无脑给push_back全替换成emplace_back的。虽然也没啥问题，但其实有时候没必要。
当然，当需要从参数来构造出对象的时候。那么 emplace_back明显会简洁许多。但此时push_back其实除了代码冗长外，其性能开销也没有比emplace_back高太多，因为
vp.push_back(Pointer(3, 4));
调用的是：
void push_back (value_type&& val);
有较真的网友提到 emplace的置入功能，还是要比这种push_back (value_type&& val)稍胜一筹，anyway。两个函数实现逻辑不同，肯定无法做到性能完全一致，但是也没到足以影响自己编码习惯的地步。总而言之当要放入 vector的对象不存在的时候，直接用 emplace_back来构造，在已存在的时候用 emplace_back或 push_back都可以。
auto不多解释了。
很多C++程序员被问『熟悉C++11吗？说一说』
答一个『auto』
没啦
auto就是用来简化长类型的（比如命名空间嵌套曾经很深）。另外auto&和auto&&(万能引用）也不多解释了。
当然滥用auto也会造成代码可读性变差。在我等不用IDE，用vim开发C++的程序员面前，auto滥用犹如噩梦。没有类型提示啊。
lambda表达式（或者说lamba对象）可能是C++程序员在回答『熟悉C++11吗？』这个问题，答完auto之后，说出的第二个新语法。
有了lambda，STL的algorithm里的函数，用起来更简洁了。
另外lambda除了替代了定义普通函数、函数对象（重载operator()）之外，还有其他便利。那就是闭包的特性。说闭包可能一时难以理解。你就可以理解成是lambda的引用捕获功能。
在lambda的参数之外，获取到了其他的参数。并且是可跨越lambda生命周期的。
唯一需要注意的是：引用捕获可能在后续lambda对象被实际调用的时候，出现引用悬空（类似空指针），从而出现core dump。
看一段冗长的代码。
class FuncFactory {
public:
void put_func(std::string, std::function<std::vector<std::string>(std::string)>);
std::function<std::vector<std::string>(std::string)> get_func(std::string);
private:
std::unordered_map<std::string, std::function<std::vector<std::string>(std::string)>> _func_map;
};
用using简化掉：
using func_t = std::function<std::vector<std::string>(std::string)>;
class FuncFactory {
public:
void put_func(std::string, func_t);
func_t get_func(std::string);
private:
std::unordered_map<std::string, func_t> _func_map;
};
从上个世纪70年代C语言诞生之始，头文件都在使用#ifndef #define #endif来避免重复包含。
#ifndef HEADER_FILE
#define HEADER_FILE
...
#endif
C++也继承了这种写法。然而时至今日还可以这样写：
#pragma once
...
这个语法很久之前就有，但并非是C++标准的一部分。但在很多编译器厂商的实现中，早早地支持了这种语法。C++11中这个语法依旧没有转正，但是由于被编译器广泛支持，几乎可以放心使用了。在Google和Facebook的C++开源项目中都有大量使用。#ifndef #define #endif终于寿终正寝。
当然在个别情况下，这个语法也存在坑：
不同于头文件防护，这条语用使得错误地在多个文件中使用相同的宏名变得不可能。另一方面，因为带#pragma once的文件是基于其文件系统层次的身份所排除的，所以若头文件在项目中有多个位置，则这不能防止包含它两次。
可以参考：https://zh.cppreference.com/w/cpp/preprocessor/impl
简而言之，pragma是基于头文件的文件路径来保持唯一的。而宏可以做到跨多个文件来保持include的唯一性。比如当你一个代码库中存在一个头文件的多个版本……
一般情况下，我们可能很少在一个项目中需要用到一个头文件的多个版本，反正我是没这种需求。
还在用下标遍历容器吗？
for (int i = 0; i < v.size(); ++i) {
cout<<v[i]<<endl;
v[i] *= 10;
}java和其他语言早有不借助下标的for - range循环，C++11也有了：
for (auto& e: v) {
cout<<e<<endl;
e *= 10;
}最好用引用&来遍历，否则如果容器中存储的是对象，会出现拷贝。当然如果你不想修改容器内元素的话，也可以用const auto& 遍历。
C++工程项目中，protobuf肯定是会大量使用的。for range也可以遍历pb的repeated字段
syntax = "proto3";
message Student {
string name = 1;
int32 score = 2;
}
message Report {
repeated Student student = 1；
}代码中：
// report 是一个Report类型的对象
for (auto& student: report.student()) {
cout<< student.name << "'s score:" << student.score << endl;
}工作中看多很多遍历pb repeated字段代码大多可以做到上面那样。但是当遍历pb repeated字段并修改其中变量的时候（mutable返回的是指针，不能直接for range），很多人还是选择了用传统的for+下标的形式来遍历。其实不用，依旧可以for range
for (int i = 0; i < report.student_size(); ++i) {
report.mutable_student(i)->set_score(60); // 60分万岁！
}啰嗦！！！！！！！！！！！可以这样写：
for (auot& student: *report.mutable_student()) {
student.set_score(60); // 60分万岁！
}你有没有这种体验：在函数中一段平铺的逻辑中，依次经历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)
do {
// 步骤1
...
if (步骤1失败) {
break;
}
// 步骤2
...
if (步骤2失败) {
break;
}
// 步骤3
...
if (步骤3失败) {
break;
}
} while(0);
// 步骤4
...
// 步骤5
...这个其实也适用于其他有do while的语言，不止C++。另外由于C++11中lambda函数的出现，你还可以这样写：
[]() {
// 步骤1
...
if (步骤1失败) {
return;
}
// 步骤2
...
if (步骤2失败) {
return;
}
// 步骤3
...
if (步骤3失败) {
return;
}
}();
// 步骤4
...
// 步骤5
...这个是在普通 lambda表达式的末尾加上了一个括号，也就是让定义的lambda可以立即执行。
这一特性也被人称为IIFE（Immediately Invoked Function Expression），即立即调用函数表达式。这是一个出自 Javascript的术语，可能不是C++中的正统称呼……
因为种种原因，从Java转C++的程序员，喜欢把C++的类写成JavaBean。动不动就set()、get()
当然这种封装也没问题，数据成员设置成private，所有的访问都通过接口函数。只是太教条的话，反而啰嗦。C++中，我喜欢把纯数据类型（只含数据）的类，直接用struct来表示。不包含任何成员函数。也不需要要用class，然后设置一个public。就用struct更直观！
【当然，这条可能有争议~】
C++11之前。如果要返回一个STL容器（或其他复杂类型）的对象怎么办?
第一种：
void split(std::string str, std:string del, std::vector<std::string>& str_list) {
// 解析字符串str，按del分隔符分割，拆成小字符串存入str_list中
...
}
// 调用方：
std::vector<std::string> str_list;
split("a:b:c:d", ":", str_list);这种用的时候不太方便。如果不是split，而且其他例子。我可能想一行连续点点点调用返回值的成员变量（foo().bar().xxx()）。无疑，上面这种会中断我的一行语句写法。
第二种：
std::shard_ptr<std::vector<string>> split(std::string str, std:string del) {
std::shard_ptr<std::vector<string>> p_str_list = std::make_shared<std::vector<std::string>>();
// 解析字符串str，按del分隔符分割，拆成小字符串存入p_str_list中
...
return p_str_list;
}或者最原始版本:
std::vector<std::string>* split(std::string str, std:string del) {
std::vector<std::string>* p_str_list = new std::vector<std::string>;
// 解析字符串str，按del分隔符分割，拆成小字符串存入p_str_list中
...
return p_str_list;
}
需要小心的处理返回值，自己控制delete掉指针，避免内存泄露。都太啰嗦。但无一例外。熟悉C++98的老前辈们都不会建议你用函数直接返回STL容器。然而事情从C++11开始起了变化。那些不熟悉C++98的新手程序员们反而写出来最优解：
std::vector<std::string> split(std::string str, std:string del) {
std::vector<std::string> str_list;
// ...
return str_list;
}相信我，没问题。
这个变化，其实也在工作中造成一些尴尬。有时候我写这种代码，在给老同事过core review的时候，生怕被批一顿代码写的烂。如果被批一顿，我自然尴尬，然后我解释一番这种写法在C++11里面没问题，那么老同事就尴尬了。
为避免这种尴尬我总会在代码附近加个注释:
// it's ok in C++11
std::vector<std::string> split(std::string str, std:string del);其实C++11之前也有这么用的。因为编译器自己做的RVO，NRVO优化，这当然是非标的。改一下编译选项可能就没啦。虽然gcc不显式关闭RVO的话，默认就开始的。但曾经我在C++98的环境下工作时，还是很少见到这种直接返回对象的写法。其实不是所有返回对象函数定义都能触发RVO，如果不清楚，C++98的程序员还是谨慎使用。
但是C++11开始，你不用担心了。
比如我们程序中有一个计数逻辑，使用了一个 unordered_map<string, int>（或map<string, int>)来对某个 string类型的tag进行计数。之前看到有同事这样写：
// freq_map 是一个 unordered_map<string, int> 类型。
// 通过某个计算获取到了一个string类型的变量tag，下面进行计数
if (freq_map.find(tag) == freq_map.end()) {
frea_map.emplace(tag, 1);
} else {
freq_map[tag] += 1;
}
// 或者这种
if (freq_map.find(tag) == freq_map.end()) {
frea_map.emplace(tag, 0);
}
freq_map[tag] += 1;
其实通通不用，上述两种大概是python中用dict来计数的写法（当年我写MapReduce任务的时候也有类似的写法）但是C++不用，因为。C++的map在使用 [] 运算符的时候会在key不存在的时候默认创建出一个值！如果value是基本数据类型，那么就是0。
所以可以直接写：
frep_map[tag]++;
// 或
freq_map[tag] += 1;
当然也正因为 [] 运算符的这个默认性质所以 Effective C++里面才有一条说要用m.insert()来插入key，value(C++11之后用emplace)而不要用m[key] = value的写法，因为后者会先构造一个空对象，再覆盖掉它。当然具体到我这里提到这个计数场景，不需要考虑这个。因为本来就需要在key不存在的时候初始化一个，而且value是基本数据类型，初始化成0，然后覆盖成1，开销不大。
Copyright© 2013-2020
All Rights Reserved 京ICP备2023019179号-8