C++代码简化之道
我是极简主义者,崇尚简洁明快的代码风格,这也可能是我不喜欢Java全家桶的原因……当然我说的简洁是要建立在不降低可读性的前提下,即不影响代码本身的表现力。如果为求代码精简而让代码晦涩艰深同样不可取。
本文会介绍10个条款,后续还会陆续更新相关的内容,请大家持续关注!
1. 善用emplace
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都可以。
2. 在不影响可读性的情况下使用auto,区分auto& 、auto&&
auto不多解释了。
很多C++程序员被问『熟悉C++11吗?说一说』
答一个『auto』
没啦
auto就是用来简化长类型的(比如命名空间嵌套曾经很深)。另外auto&和auto&&(万能引用)也不多解释了。
当然滥用auto也会造成代码可读性变差。在我等不用IDE,用vim开发C++的程序员面前,auto滥用犹如噩梦。没有类型提示啊。
3. lambda表达式替换手写函数和函数对象
lambda表达式(或者说lamba对象)可能是C++程序员在回答『熟悉C++11吗?』这个问题,答完auto之后,说出的第二个新语法。
有了lambda,STL的algorithm里的函数,用起来更简洁了。
另外lambda除了替代了定义普通函数、函数对象(重载operator())之外,还有其他便利。那就是闭包的特性。说闭包可能一时难以理解。你就可以理解成是lambda的引用捕获功能。
在lambda的参数之外,获取到了其他的参数。并且是可跨越lambda生命周期的。
唯一需要注意的是:引用捕获可能在后续lambda对象被实际调用的时候,出现引用悬空(类似空指针),从而出现core dump。
4. 给冗长的类型建立别名,尤其是std::function类型
看一段冗长的代码。
-
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;
-
};
-
5. 头文件中使用#pragma once替换老破旧#ifndef #define #endif
从上个世纪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的唯一性。比如当你一个代码库中存在一个头文件的多个版本……
一般情况下,我们可能很少在一个项目中需要用到一个头文件的多个版本,反正我是没这种需求。
6. 善用for range遍历容器,也可以针对PB的repeated字段(甚至mutable)
还在用下标遍历容器吗?
-
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分万岁!
-
}
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)
-
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++中的正统称呼……
8. 某些情况下用struct替代class,避免把C++类写成JavaBean
因为种种原因,从Java转C++的程序员,喜欢把C++的类写成JavaBean。动不动就set()、get()
当然这种封装也没问题,数据成员设置成private,所有的访问都通过接口函数。只是太教条的话,反而啰嗦。C++中,我喜欢把纯数据类型(只含数据)的类,直接用struct来表示。不包含任何成员函数。也不需要要用class,然后设置一个public。就用struct更直观!
【当然,这条可能有争议~】
9. 函数直接返回STL容器或对象。不要返回指针,也不需要给函数加出参
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开始,你不用担心了。
10. 利用unordered_map/map的[]运算符的默认行为
比如我们程序中有一个计数逻辑,使用了一个 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,开销不大。
文章来源: blog.csdn.net,作者:C语言与CPP编程,版权归原作者所有,如需转载,请联系作者。
原文链接:blog.csdn.net/weixin_41055260/article/details/120031048
- 点赞
- 收藏
- 关注作者
评论(0)