C++代码简化之道

C++代码简化之道_第1张图片

我是极简主义者,崇尚简洁明快的代码风格,这也可能是我不喜欢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 vp;
std::map mp;

Point p(1, 2);
vp.push_back(p);
vp.push_back(Pointer(3, 4));

Point p1(10, 20);
mp.insert(std::pair("key1", p1));
Point p2(100, 200);
mp.insert(std::make_pair("key2", p2));

C++11之后:

std::vector vp;
std::map 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::string)>);
    std::function(std::string)> get_func(std::string);
private:
    std::unordered_map(std::string)>> _func_map;
};

用using简化掉:

using func_t = std::function(std::string)>;

class FuncFactory {
public:
    void put_func(std::string, func_t);
    func_t get_func(std::string);
private:
    std::unordered_map _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<

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

for (auto& e: v) {
    cout<

最好用引用&来遍历,否则如果容器中存储的是对象,会出现拷贝。当然如果你不想修改容器内元素的话,也可以用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& str_list) {
   // 解析字符串str,按del分隔符分割,拆成小字符串存入str_list中
   ...
}

// 调用方:
std::vector str_list;
split("a:b:c:d", ":", str_list);

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

第二种:

std::shard_ptr> split(std::string str, std:string del) {
    std::shard_ptr> p_str_list = std::make_shared>();
    // 解析字符串str,按del分隔符分割,拆成小字符串存入p_str_list中
    ...
    return p_str_list;
}

或者最原始版本:

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

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

std::vector split(std::string str, std:string del) {
    std::vector str_list;
    // ...
    return str_list;
}

相信我,没问题。

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

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

// it's ok in C++11
std::vector 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(或map)来对某个 string类型的tag进行计数。之前看到有同事这样写:

// freq_map 是一个 unordered_map 类型。
// 通过某个计算获取到了一个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,开销不大。

你可能感兴趣的:(C语言与C++编程,c++,java,twitter,编程语言,python)