Table of Contents:

github: https://github.com/chronolaw/cpp_study

 开篇词 | 把C++从“神坛”上拉下来,这次咱这么学

 有两种写程序的方式:一种是把代码写得非常复杂,以至于“看不出明显的错误”;另一种是把代码写得非常简单,以至于“明显看不出错误”。
 “把正确的代码改快速”,要比“把快速的代码改正确”,容易得太多。

 课前准备 | 搭建实验环境

Linux 也是版本众多,最常见的是 RedHat 系的 CentOS 和 Debian 系的 Ubuntu。
这两个被很多企业广泛采用,但 CentOS 通常比较“稳定”,更新较慢,CentOS 7 的Gcc版本是 4.8,对 C++ 标准的支持很不完善,极大地限制了C++ 能力的发挥。
而Ubuntu 16.04的 GCC版本是 5.4,完美支持 C++11/14。
当然,你要是愿意安装更新的 18.04、20.04 也没有问题,它们里面的 GCC 版本更高,支持 C++17,只不过有点“功能过剩”。
Ubuntu的版本基本上是和年份一致的,如20版的是20年的。

 01 | 重新认识C++:生命周期和编程范式

 C++ 程序的生命周期

一个 C++ 程序从“诞生”到“消亡”,要经历这么几个阶
段:编码(Coding)、预处理(Pre-processing)、编译(Compiling)和运行(Running)。
“预处理”的目的是文字替换,用到的就是我们熟悉的各种预处理指令,比如 #include#define#if 等,实现“预处理编程”。
不过,你要注意的是,它们都以符号“#”开头,虽然是 C++ 程序的一部分,但严格来说不属于 C++ 语言的范畴,因为它走的是预处理器。

在编译的过程中,编译器还会根据 C++ 语言规则检查程序的语法、语义是否正确,发现错误就会产生“编译失败”。这就是最基本的 C++“静态检查”。
在处理源码时,由于编译器是依据 C++ 语法检查各种类型、函数的定义,所以,在这个阶段,我们就能够以编译器为目标进行编程,有意识地控制编译器的行为。这里有个新名词,叫“模板元编程”。不过,“模板元编程”比较复杂,不太好理解,属于比较高级的用法.

还有,别忘了软件工程里的“蝴蝶效应”“混沌理论”,大概意思是:一个 Bug 在越早的阶段发现并解决,它的价值就越高;一个 Bug 在越晚的阶段发现并解决,它的成本就越高。所以,依据这个生命周期模型,我们应该在“编码”“预处理”“编译”这前面三个阶段多下功夫,消灭 Bug,优化代码,尽量不要让 Bug 在“运行”阶段才暴露出来,也就是所谓的“把问题扼杀在萌芽期”。

 C++ 语言的编程范式(Paradigm)

“编程范式”是一种“方法论”,就是指导你编写代码的一些思路、规则、习惯、定式和常用语
C++(11/14 以后)支持“面向过程”“面向对象”“泛型”“模板元”“函数式”这五种主要的编程范式

说得具体一点,就是要认识、理解这些范式的优势和劣势,在程序里适当混用,取长补短才是“王道”。
说到这儿,你肯定很关心,该选择哪种编程范式呢?
拿我自己来说,我的出发点是“尽量让周围的人都能看懂代码”,所以常用的范式是“过程+ 对象 + 泛型”,再加上少量的“函数式”,慎用“模板元”。

如果是开发直接面对用户的普通应用(Application),那么你可以再研究一下“泛型”和“函数式”,就基本可以解决 90% 的开发问题了;如果是开发面向程序员的库(Library),那么你就有必要深入了解“泛型”和“模板元”,优化库的接口和运行效率。

 02 | 编码阶段能做什么:秀出好的code style

 空格与空行
不同逻辑段的代码用空格隔开,加上了适当的空格和空行后,代码就显得错落有致,舒缓得当
 起个好名字
一些已经在程序员之间形成了普遍共识的变量名,比如用于循环的i/j/k、用于计数的 count、表示指针的 p/ptr、表示缓冲区的 buf/buffer、表示变化量的delta、表示总和的 sum。
全局变量前缀:“g_”前缀(global)  成员变量加“m_”前缀(member)
变量 / 函数的名字长度与它的作用域成正比

* 代码风格检查工具
cpplint是Google开发的一个C++代码风格检查工具,用python编写的,如果是遵循google code style的,可以使用cpplint作为代码规范的一个检查工具。
空格、折行这类的可以用IDE带的格式化代码的工具。

 03 | 预处理阶段能做什么:宏定义和条件编译

一般来说,预处理指令不应该受C++ 代码缩进层次的影响,不管是在函数、类里,还是在 if、for 等语句里,永远是顶格写。

#if __linux__ // 预处理检查宏是否存在
#    define HAS_LINUX 1 // 宏定义,有缩进
#endif // 预处理条件语句结束

 包含文件(#include

#include,它的作用是“包含文件”。注意,不是“包含头文件”,而是可以包含任意的文件。
除了最常用的包含头文件,你还可以利用“#include”的特点玩些“小花样”,编写一些代码片段,存进“*.inc”文件里,然后有选择地加载,用得好的话,可以实现“源码级别的抽象”
比如说,有一个用于数值计算的大数组,里面有成百上千个数,放在文件里占了很多地方,
特别“碍眼”:

static uint32_t calc_table[] = { // 非常大的一个数组,有几十行
0x00000000, 0x77073096, 0xee0e612c, 0x990951ba,
0x076dc419, 0x706af48f, 0xe963a535, 0x9e6495a3,
0x0edb8832, 0x79dcb8a4, 0xe0d5e91e, 0x97d2d988,
0x09b64c2b, 0x7eb17cbd, 0xe7b82d07, 0x90bf1d91,
...
};

可以用来代替

static uint32_t calc_table[] = {
# include "calc_values.inc" // 非常大的一个数组,细节被隐藏
};

 条件编译

#ifdef __cplusplus // 定义了这个宏就是在用C++编译
    extern "C" { // 函数按照C的方式去处理
#endif
    void a_c_function(int a);
#ifdef __cplusplus // 检查是否是C++编译
    } // extern "C" 结束
#endif
#if __cplusplus >= 201402 // 检查C++标准的版本号
    cout << "c++14 or later" << endl; // 201402就是C++14
#elif __cplusplus >= 201103 // 检查C++标准的版本号
    cout << "c++11 or before" << endl; // 201103是C++11
#else // __cplusplus < 201103 // 199711是C++98
# error "c++ is too old" // 太低则预处理报错
#endif // __cplusplus >= 201402 // 预处理语句结束

 04 | 编译阶段能做什么:属性和静态断言

和预处理阶段一样,在这里你也可以“面向编译器编程”,用一些指令或者关键字让编译器按照你的想法去做一些事情。

 属性(attribute)

虽然编译器非常聪明,但因为 C++ 语言实在是太复杂了,偶尔它也会“自作聪明”或者“冒傻气”。如果有这么一个东西,让程序员来手动指示编译器这里该如何做、那里该如何做,就有可能会生成更高效的代码。
在 C++11 之前,标准里没有规定这样的东西,但 GCC、VC 等编译器发现这样做确实很有用,于是就实现出了自己“编译指令”,在 GCC 里是__ attribute __,在 VC 里是__declspec。不过因为它们不是标准,所以名字显得有点“怪异”。
到了 C++11,标准委员会终于认识到了“编译指令”的好处,于是就把“民间”用法升级为“官方版本”,起了个正式的名字叫“属性”。你可以把它理解为给变量、函数、类等“贴”上一个编译阶段的“标签”,方便编译器识别处理。
C++11:noreturn 、carries_dependency
C++14:deprecated
目前的 C++17 和 C++20 又增加了五六个新属性,比如 fallthrough、likely,但我觉得,标准委员会的态度还是太“保守”了,在实际的开发中,这些真的是不够用。

// 编译的时候用到这个函数的地方会报警告
[[deprecated("deadline:2020-12-31")]] // C++14 or later
int old_func();

好在“属性”也支持非标准扩展,允许以类似名字空间的方式使用编译器自己的一些“非官方”属性,比如,GCC 的属性都在“gnu::”里。下面我就列出几个比较有用的:
 deprecated:与 C++14 相同,但可以用在 C++11 里。
 unused:用于变量、类型、函数等,表示虽然暂时不用,但最好保留着,因为将来可能会用。
 constructor:函数会在 main() 函数之前执行,效果有点像是全局对象的构造函数。
 destructor:函数会在 main() 函数结束之后执行,有点像是全局对象的析构函数。
 always_inline:要求编译器强制内联函数,作用比 inline 关键字更强。
 hot:标记“热点”函数,要求编译器更积极地优化。

在没有这个属性的时候,如果有暂时用不到的变量,我们只能用“(void) var;”的方式假装
用一下,来“骗”过编译器,属于“不得已而为之”的做法。
那么现在,我们就可以用“unused”属性来清楚地告诉编译器:这个变量我暂时不用,请
不要过度紧张,不要发出警告来烦我:

[[gnu::unused]] // 声明下面的变量暂不使用,不是错误
int nouse;

 静态断言(static_assert)

属性”像是给编译器的一个“提示”“告知”,无法进行计算,还算不上是编程,而“静态断言”,就有点编译阶段写程序的味道了。
assert 虽然是一个宏,但在预处理阶段不生效,而是在运行阶段才起作用,所以又叫“动态断言”。
static_assert 可以在编译阶段定义各种前置条件,充分利用 C++ 静态类型语言的优势,让编译器执行各种检查,避免把隐患带到运行阶段。在编译阶段计算常数和类型,如果断言失败就会导致编译错误。它也是迈向模板元编程的第一步。
static_assert 运行在编译阶段,只能看到编译时的常数类型,看不到运行时的变量、指针、内存数据等,所以不要简单地把 assert 的习惯搬过来用。

注意点:在用“静态断言”的时候,你就要在脑子里时刻“绷紧一根弦”,把自己代入编译器的角色,像编译器那样去思考,看看断言的表达式是不是能够在编译阶段算出结果。
比如:
比如说,这节课刚开始时的斐波拉契数列计算函数,可以用静态断言来保证模板参数必须大于等于零:

template<int N>
struct fib
{
    static_assert(N >= 0, "N >= 0");
    static const int value =
        fib<N - 1>::value + fib<N - 2>::value;
};

不过这句话说起来容易做起来难,计算数字还好说,在泛型编程的时候,怎么检查模板类型呢?比如说,断言是整数而不是浮点数、断言是指针而不是引用、断言类型可拷贝可移动……
这些检查条件表面上看好像是“不言自明”的,但要把它们用 C++ 语言给精确地表述出来,可就没那么简单了。所以,想要更好地发挥静态断言的威力,还要配合标准库里的type_traits,它提供了对应这些概念的各种编译期“函数”。

// 假设T是一个模板参数,即template<typename T>
static_assert(
    is_integral<T>::value, "int");
static_assert(
    is_pointer<T>::value, "ptr");
static_assert(
    is_default_constructible<T>::value, "constructible");

 05 | 面向对象编程:怎样才能写出一个“好”的类?

面向对象编程的基本出发点是对现实世界的模拟,把问题中的实体抽象出来,封装为程序里的类和对象,
“面向对象编程”的关键点是“抽象”和“封装”,而“继承”“多态”并不是核心,只能算是附加品。
所以,我建议你在设计类的时候尽量少用继承和虚函数。
特别的,如果完全没有继承关系,就可以让对象不必承受“父辈的重担”(父类成员、虚表等额外开销),轻装前行,更小更快。没有隐含的重用代码也会降低耦合度,让类更独立,更容易理解。

如果非要用继承不可,那么我觉得一定要控制继承的层次,如果继承深度超过三层,就说明有点“过度设计”了。
在设计类接口的时候,我们也要让类尽量简单、“短小精悍”,只负责单一的功能。
如果很多功能混在了一起,出现了“万能类”“意大利面条类”(有时候也叫 God
Class),就要应用设计模式、重构等知识,把大类拆分成多个各负其责的小类。

我还看到过很多人有一种不好的习惯,就是喜欢在类内部定义一些嵌套类,美其名曰“高内聚”。但恰恰相反,这些内部类反而与上级类形成了强耦合关系,也是另一种形式的“万能类”。
其实,这本来是名字空间该做的事情,用类来实现就有点“越权”了。正确的做法应该是,定义一个新的名字空间,把内部类都“提”到外面,降低原来类的耦合度和复杂度。
编码准则:
1. 用final显式地禁用继承
2. 只使用 public 继承
3. = default  明确使用默认的    = delete 明确禁用某个函数
4. 用explicit防止意外的隐式类型转换

 常用技巧

 委托构造(delegating constructor)。
在 C++11 里,你就可以使用“委托构造”的新特性,一个构造函数直接调用另一个构造函数,把构造工作“委托”出去,既简单又高效
 成员变量初始化(In-class member initializer)。
在 C++11 里,你可以在类里声明变量的同时给它赋值,实现初始化,这样不但简单清晰,也消除了隐患(列表初始化可能会被漏掉)
* 类型别名(Type Alias)
在写类的时候,我们经常会用到很多外部类型,比如标准库里的 string、vector,还有其他的第三方库和自定义类型。这些名字通常都很长(特别是带上名字空间、模板参数),书写起来很不方便,这个时候我们就可以在类里面用 using 给它们起别名,不仅简化了名字,同时还能增强可读性。

using uint_t = unsigned int; // using别名
typedef unsigned int uint_t; // 等价的typedef

 06 | auto/decltype:为什么要有自动类型推导?

 auto

因为 C++ 是一种静态强类型的语言,任何变量都要有一个确定的类型,否则就不能用。
在“自动类型推导”出现之前,我们写代码时只能“手动推导”,也就是说,在声明变量的时候,必须要明确地给出类型。
对于比如 int、double这类的变量类型还好说,但在泛型编程的时候,类型特别的长,这就迫使我们去和编译器“斗智斗勇”,只有写对了类型,编译器才会“放行”(编译通过)
除了简化代码,auto 还避免了对类型的硬编码,也就是说变量类型不是“写死”的,而是能够“自动”适应表达式的类型。比如,你把 map 改为 unordered_map,那么后面
的代码都不用动。这个效果和类型别名有点像,但你不需要写出 typedef 或者 using,全由 auto“代劳”
另外,“自动类型推导”,是编译阶段的特殊指令,指示编译器去计算类型。
注意点:
 auto 的“自动推导”能力只能用在“初始化”的场合。
 类里不能使用auto推导类型
 auto 总是推导出值类型,绝不会是“引用”;
 auto 可以附加上 const、volatile、*、& 这样的类型修饰符,得到新的类型。

范围for循环一般都用auto,为了保证效率,最好使用“const auto&”或者“auto&
在 C++14 里,auto 还新增了一个应用场合,就是能够推导函数返回值,这样在写复杂函数的时候,比如返回一个 pair、容器或者迭代器,就会很省事。

auto get_a_set() // auto作为函数返回值的占位符
{
    std::set<int> s = {1,2,3};
    return s;
}

 decltype

auto 只能用于初始化,decltype 不仅能够推导出值类型,还能够推导出引用类型,也就是表达式的“原始类型”。

int x = 0; // 整型变量
decltype(x) x1;

decltype有个缺点,就是写起来略麻烦,特别在用于初始化的时候,表达式要重复两次(左边的类型计算,右边的初始化),把简化代码的优势完全给抵消了。
所以,C++14 就又增加了一个“decltype(auto)”的形式,既可以精确推导类型,又能像auto 一样方便使用。

int x = 0; // 整型变量
decltype(auto) x1 = (x); // 推导为int&,因为(expr)是引用类型
decltype(auto) x2 = &x; // 推导为int*
decltype(auto) x3 = x1; // 推导为int&

再来看 decltype 怎么用最合适。
它是 auto 的高级形式,更侧重于编译阶段的类型计算,所以常用在泛型编程里,获取各种类型,配合 typedef 或者 using 会更加方便。当你感觉“这里我需要一个特殊类型”的时候,选它就对了。
比如说,定义函数指针在 C++ 里一直是个比较头疼的问题,因为传统的写法实在是太怪异了。但现在就简单了,你只要手里有一个函数,就可以用 decltype 很容易得到指针类型。

// UNIX信号函数的原型,看着就让人晕,你能手写出函数指针吗?
void (*signal(int signo, void (*func)(int)))(int)
// 使用decltype可以轻松得到函数指针类型
using sig_func_ptr_t = decltype(&signal) ;

在定义类的时候,因为 auto 被禁用了,所以这也是 decltype 可以“显身手”的地方。它可以搭配别名任意定义类型,再应用到成员变量、成员函数上,变通地实现 auto 的功能。

class DemoClass final
{
    public:
        using set_type = std::set<int>; // 集合类型别名
    private:
        set_type m_set; // 使用别名定义成员变量

        // 使用decltype计算表达式的类型,定义别名
        using iter_type = decltype(m_set.begin());

        iter_type m_pos; // 类型别名定义成员变量 
};

 07 | const/volatile/mutable:常量/变量究竟是怎么回事?

const 常量虽然不是“真正的常数”,但在大多数情况下,它都可以被认为是常数,在运行期间不会改变。编译器看到 const 定义,就会采取一些优化手段,比如把所有 const 常量出现的地方都替换成原始值。

关键字 mutable
效果是:允许 const 成员函数改写 mutable 成员变量

在我看来,,mutable 像是 C++ 给 const 对象打的一个“补丁”,让它部分可变。因为对象与普通的 int、double 不同,内部会有很多成员变量来表示状态,但因为“封装”特性,外界只能看到一部分状态,判断对象是否 const 应该由这些外部可观测的状态特征来决定。
比如说,对象内部用到了一个 mutex 来保证线程安全,或者有一个缓冲区来暂存数据,再或者有一个原子变量做引用计数……这些属于内部的私有实现细节,外面看不到,变与不变不会改变外界看到的常量性。这时,如果 const 成员函数不允许修改它们,就有点说不过去了。
所以,对于这些有特殊作用的成员变量,你可以给它加上 mutable 修饰,解除 const 的限制,让任何成员函数都可以操作它。

class DemoClass final
{
    private:
    mutable mutex_type m_mutex; // mutable成员变量
    public:
    void save_data() const // const成员函数
    {
        // do someting with m_mutex
    }
};

 08 | smart_ptr:智能指针到底“智能”在哪里?

C++ 里也是有垃圾回收的,不过不是 Java、Go 那种严格意义上的垃圾回收,而是广义上的垃圾回收,这就是构造 / 析构函数和 RAII 惯用法(Resource Acquisition Is Initialization)。

我们可以应用代理模式,把裸指针包装起来,在构造函数里初始化,在析构函数里释放。这样当对象失效销毁时,C++ 就会自动调用析构函数,完成内存释放、资源回收等清理工作。
智能指针就是代替你来干这些“脏活累活”的。它完全实践了 RAII,包装了裸指针,而且因为重载了 * 和 -> 操作符,用起来和原始指针一模一样

 unique_ptr

unique_ptr<string> ptr2(new string("hello")); // string智能指针
assert(*ptr2 == "hello"); // 可以使用*取内容
assert(ptr2->size() == 5); // 可以使用->调用成员函数

unique_ptr 虽然名字叫指针,用起来也很像,但它实际上并不是指针,而是一个对象。所以,不要企图对它调用 delete,它会自动管理初始化时的指针,在离开作用域时析构释放内存。
另外,它也没有定义加减运算,不能随意移动指针地址,这就完全避免了指针越界等危险操作

ptr1++; // 导致编译错误
ptr2 += 2; // 导致编译错误

易犯错误:不初始化,而是声明后直接使用

unique_ptr<int> ptr3; // 未初始化智能指针
*ptr3 = 42 ; // 错误!操作了空指针

为了避免这种低级错误,你可以调用工厂函数 make_unique(),强制创建智能指针的时候必须初始化。同时还可以利用自动类型推导的 auto,少写一些代码:

auto ptr3 = make_unique<int>(42); // 工厂函数创建智能指针
assert(ptr3 && *ptr3 == 42);
auto ptr4 = make_unique<string>("god of war"); // 工厂函数创建智能指针
assert(!ptr4->empty());

make_unique() 要求 C++14,你可以自己实现一个:

template<class T, class... Args> // 可变参数模板
std::unique_ptr<T> // 返回智能指针
my_make_unique(Args&&... args) // 可变参数模板的入口参数
{
    return std::unique_ptr<T>( // 构造智能指针
        new T(std::forward<Args>(args)...)); // 完美转发
}

unique_ptr不允许共享,任何时候只能有一个“人”持有它。故禁止了拷贝和赋值,所以,在向另一个 unique_ptr 赋值的时候,要特别留意,必std::move() 函数显式地声明所有权转移。
不能拷贝unique_ptr的规则有一个例外:我们可以拷贝或赋值一个将要被销毁的unique_ptr。上面的my_make_unique就是return了一个unique_ptr

 shared_ptr

shared_ptr它的所有权是可以被安全共享的,也就是说支持拷贝赋值,允许被多个“人”同时持有,就像原始指针一样

auto ptr1 = make_shared<int>(42);  // 工厂函数创建智能指针
assert(ptr1 && ptr1.unique() );         // 此时智能指针有效且唯一
auto ptr2 = ptr1;                               // 直接拷贝赋值,不需要使用move()
assert(ptr1 && ptr2);                        // 此时两个智能指针均有效
assert(ptr1 == ptr2);                        // shared_ptr可以直接比较
// 两个智能指针均不唯一,且引用计数为2
assert(!ptr1.unique() && ptr1.use_count() == 2);
assert(!ptr2.unique() && ptr2.use_count() == 2);

shared_ptr 支持安全共享的秘密在于内部使用了“引用计数”,当引用计数减少到0才真正的释放。
因为 shared_ptr 具有完整的值语义(即可以拷贝赋值),所以,它可以在任何场合替代原始指针,而不用再担心资源回收的问题,比如用于容器存储指针、用于函数安全返回动态创建的对象,等等
注意点:
0. shared_ptr 有少量的管理成本,也会引发一些难以排查的错误,所以不要过度使用。 
1. 因为我们把指针交给了 shared_ptr 去自动管理,但在运行阶段,引用计数的变动是很复杂的,很难知道它真正释放资源的时机。你要特别小心对象的析构函数,不要有非常复杂、严重阻塞的操作。一旦 shared_ptr 在某个不确定时间点析构释放资源,就会阻塞整个进程或者线程,“整个世界都会静止不动”
2. shared_ptr 的引用计数也导致了一个新的问题,就是“循环引用”,这在把 shared_ptr作为类成员的时候最容易出现,典型的例子就是链表节点。

 weak_ptr

weak_ptr 顾名思义,功能很“弱”。它专门为打破循环引用而设计,只观察指针,不会增加和减少引用计数,但在需要的时候,可以调用成员函数 lock(),升级到shared_ptr。
C++11标准虽然将 weak_ptr 定位为智能指针的一种,但该类型指针通常不单独使用,因为连、 ->都没重载(没有实际用处),只能和 shared_ptr 类型指针搭配使用。甚至于,我们可以将 weak_ptr 类型指针视为 shared_ptr 指针的一种辅助工具,借助 weak_ptr 类型指针, 我们可以获取 shared_ptr 指针的一些状态信息,比如有多少指向相同的 shared_ptr 指针、shared_ptr 指针指向的堆内存是否已经被释放等等。

weak_ptr 模板类中没有重载 * 和 -> 运算符,这也就意味着,weak_ptr 类型指针只能访问所指的堆内存,而无法修改它。

成员方法:

operator=()   //重载 = 赋值运算符,是的 weak_ptr 指针可以直接被 weak_ptr 或者 shared_ptr 类型指针赋值。
swap(x)      // 其中 x 表示一个同类型的 weak_ptr 类型指针,该函数可以互换 2 个同类型 weak_ptr 指针的内容。
reset()    // 将当前 weak_ptr 指针置为空指针。
use_count()  //查看指向和当前 weak_ptr 指针相同的 shared_ptr 指针的数量。
expired()  // 判断当前 weak_ptr 指针为否过期(指针为空,或者指向的堆内存已经被释放)。
lock()     // 如果当前 weak_ptr 已经过期,则该函数会返回一个空的 shared_ptr 指针;反之,该函数返回一个和当前 weak_ptr 指向相同的 shared_ptr 指针。

循环引用
在把 shared_ptr作为类成员的时候最容易出现,典型的例子就是链表节点

class Node final
{
public:
    using this_type = Node;
    using shared_type = std::shared_ptr<this_type>;
public:
    shared_type next; // 使用智能指针来指向下一个节点
};

auto n1 = make_shared<Node>(); // 工厂函数创建智能指针
auto n2 = make_shared<Node>(); // 工厂函数创建智能指针

assert(n1.use_count() == 1); // 引用计数为1
assert(n2.use_count() == 1);
n1->next = n2; // 两个节点互指,形成了循环引用
n2->next = n1;
assert(n1.use_count() == 2); // 引用计数为2
assert(n2.use_count() == 2); // 无法减到0,无法销毁,导致内存泄漏
// 出作用域析构时n1减1,n2减1,但因彼此都相互引用,所有无法减到0

改正方式

class Node final
{
public:
    using this_type = Node;
    // 注意这里,别名改用weak_ptr
    using shared_type = std::weak_ptr<this_type>;
public:
    shared_type next; // 因为用了别名,所以代码不需要改动
};
auto n1 = make_shared<Node>(); // 工厂函数创建智能指针
auto n2 = make_shared<Node>(); // 工厂函数创建智能指针
n1->next = n2; // 两个节点互指,形成了循环引用
n2->next = n1;
assert(n1.use_count() == 1); // 因为使用了weak_ptr,引用计数为1
assert(n2.use_count() == 1); // 打破循环引用,不会导致内存泄漏
if (!n1->next.expired()) { // 检查指针是否有效
    auto ptr = n1->next.lock(); // lock()获取shared_ptr
    assert(ptr == n2);
}

 09 | exception:怎样才能用好异常?

异常只是 C++ 为了处理错误而提出的一种解决方案,当然也不会是唯一的一种。
在 C++ 之前,处理异常的基本手段是错误码。函数执行后,需要检查返回值或者全局的 errno,看是否正常,如果出错了,就执行另外一段代码处理错误.

错误码缺点:
1. 这种做法很直观,但也有一个问题,那就是正常的业务逻辑代码与错误处理代码混在了一起,看起来很乱,你的思维要在两个本来不相关的流程里来回跳转。而且,有的时候,错误处理的逻辑要比正常业务逻辑复杂、麻烦得多,看了半天,你可能都会忘了它当初到底要干什么了,容易引起新的错误。
2. 错误码还有另一个更大的问题:它是可以被忽略的。也就是说,你完全可以不处理错误,“假装”程序运行正常,继续跑后面的代码,这就可能导致严重的安全隐患。

用异常的好处:
1. 异常的处理流程是完全独立的,throw 抛出异常后就可以不用管了,错误处理代码都集中在专门的 catch 块里。这样就彻底分离了业务逻辑与错误逻辑,看起来更清楚。
2. 异常是绝对不能被忽略的,必须被处理。如果你有意或者无意不写 catch 捕获异常,那么它会一直向上传播出去,直至找到一个能够处理的 catch 块。如果实在没有,那就会导致程序立即停止运行,明白地提示你发生了错误,而不会“坚持带病工作”。
3. 异常可以用在错误码无法使用的场合,这也算是 C++ 的“私人原因”。因为它比 C 语言多了构造 / 析构函数、操作符重载等新特性,有的函数根本就没有返回值,或者返回值无法表示错误,而全局的 errno 实在是“太不优雅”了,与 C++ 的理念不符,所以也必须使用异常来报告错误。

C++ 里对异常的定义非常宽松,任何类型都可以用 throw 抛出,也就是
说,你可以直接把错误码(int)、或者错误消息(char*string)抛出,catch 也能接住,然后处理。
但我建议你最好不要“图省事”,因为 C++ 已经为处理异常设计了一个配套的异常类型体系,定义在标准库的 <stdexcept> 头文件里。

异常也与上一讲的智能指针密切相关,如果你决定使用异常,为了确保出现异常的时候资源会正确释放,就必须禁用裸指针,改成智能指针,用 RAII 来管理内存。
由于异常出现和处理的时机都不好确定,当前的 C++ 也没有在语言层面提出更好的机制,所以,你还要在编码阶段写好文档和注释,说清楚哪些函数、什么情况下会抛出什么样的异常,应如何处理,加上一些“软约束”。
小结:
1. 异常是针对错误码的缺陷而设计的,它不能被忽略,而且可以“穿透”调用栈,逐层传播到其他地方去处理;
2. 使用 try-catch 机制处理异常,能够分离正常流程与错误处理流程,让代码更清晰; 
3. throw 可以抛出任何类型作为异常,但最好使用标准库里定义的 exception 类; 
4. 完全用或不用异常处理错误都不可取,而是应该合理分析,适度使用,降低异常的成本;
5. 关键字 noexcept 标记函数不抛出异常,可以让编译器做更好的优化。

 10 | lambda:函数式编程带来了什么?

在 C/C++ 里,所有的函数都是全局的,没有生存周期的概念(static、名字空间的作用很弱,只是简单限制了应用范围,避免名字冲突)
而且函数也都是平级的,不能在函数里再定义函数,也就是不允许定义嵌套函数、函数套函数
所以,在面向过程编程范式里,函数变量虽然是程序里最关键的两个组成部分,但却因为没有值、没有作用域而不能一致地处理。函数只能是函数,变量只能是变量。
因为 lambda 表达式是一个变量,所以,我们就可以“按需分配”,随时随地在调用点“就地”定义函数,限制它的作用域和生命周期,实现函数的局部化。
而且,因为 lambda 表达式和变量一样是“一等公民”,用起来也就更灵活自由,能对它做各种运算,生成新的函数。这就像是数学里的复合函数那样,把多个简单功能的小
lambda 表达式组合,变成一个复杂的大 lambda 表达式。

C++ 里的 lambda 表达式除了可以像普通函数那样被调用,还有一个普通函数所不具备的特殊本领,就是可以“捕获”外部变量,在内部的代码里直接操作。
看到这里,如果你用过 JavaScript,那么一定会有种眼熟的感觉。没错,lambda 表达式就是在其他语言中大名鼎鼎的“闭包”(closure),这让它真正超越了函数和函数对象。不过在c++中闭包的作用不大,因为有比较强的面向对象编程。

在 lambda 表达式赋值的时需用auto关键字,在 C++ 里,每个 lambda 表达式都会有一个独特的类型,而这个类型只有编译器才知道,我们是无法直接写出来的,所以必须用 auto。
可以使用 auto 自动推导类型存储 lambda 表达式,但 C++ 鼓励尽量就地匿名使用,缩小作用域;

泛型的 lambda
在 C++14 里,lambda 表达式又多了一项新本领,可以实现“泛型化”,相当于简化了的模板函数,具体语法还是利用了“多才多艺”的 auto

auto f = [](const auto& x) // 参数使用auto声明,泛型化
{
    return x + x;
};
cout << f(3) << endl; // 参数类型是int
cout << f(0.618) << endl; // 参数类型是double
string str = "matrix";
cout << f(str) << endl; // 参数类型是string

注意点:
捕获引用时必须要注意外部变量的生命周期,防止变量失效

 11 | 一枝独秀的字符串:C++也能处理文本?

只有语言、标准库“双剑合璧”,才能算是真正的 C++。
看一下官方发布的标准文档吧(C++14),全文有 1300 多页,而语言特性只有 400 出头,不足三分之一,其余的篇幅全是在讲标准库,可见它的份量有多重。

字符串是“文本”,里面的字符之间是强关系,顺序不能随便调换,否则就失去了意义,通常应该视为一个整体来处理。而容器是“集合”,里面的元素之间没有任何关系,可以随意增删改,对容器更多地是操作里面的单个元素。

但有的时候,我们也确实需要存储字符的容器,比如字节序列数据缓冲区,这该怎么办呢?
这个时候,我建议你最好改用 vector<char>,它的含义十分“纯粹”,只存储字符,没有 string 那些不必要的成本,用起来也就更灵活一些。

 1. 字面量后缀

C++11 为方便使用字符串,新增了一个字面量的后缀“s”,明确地表示它是 string 字符串类型,而不是 C 字符串,这就可以利用 auto 来自动类型推导,而且在其他用到字符串的地方,也可以省去声明临时字符串变量的麻烦,效率也会更高

using namespace std::literals::string_literals; //必须打开名字空间
auto str = "std string"s; // 后缀s,表示是标准字符串,直接类型推导

 2. 原始字符串

如果使用原始字符串的话,就没有这样的烦恼了,它不会对字符串里的内容做任何转义,完全保持了“原始风貌”,即使里面有再多的特殊字符都不怕

auto str = R"(\r\n\t\")"; // 原始字符串:\r\n\t\"

 3. 字符串转换函数

stoi()、stol()、stoll() 等把字符串转换成整数;
stof()、stod() 等把字符串转换成浮点数;
to_string() 把整数、浮点数转换成字符串

 4. 字符串视图类

string_view是c++17标准库提供的一个类,它提供一个字符串的视图,即可以通过这个类以各种方法“观测”字符串,但不允许修改字符串。
它内部只保存一个指针和长度,无论是拷贝,还是修改,都非常廉价构造和求substr都是O(1)的复杂度
std的string的构造不可避免的会设计内存分配和拷贝。而string_view只是一个字符串的视图,构造函数可以避免拷贝,做到O(1)复杂度。
因为string_view并不拷贝内存,所以要特别注意它所指向的字符串的生命周期。string_view指向的字符串,不能再string_view死亡之前被回收。

 5. 正则表达式

C++ 正则表达式主要有两个类。
regex:表示一个正则表达式,是 basic_regex 的特化形式;
smatch:表示正则表达式的匹配结果,是 match_results 的特化形式。
C++ 正则匹配有三个算法,注意它们都是“只读”的,不会变动原字符串。
regex_match():完全匹配一个字符串;
regex_search():在字符串里查找一个正则匹配;
regex_replace():正则查找再做替换。会返回修改后的新字符串

在写正则的时候,记得最好要用“原始字符串”,不然转义符绝对会把你折腾得够呛。

在使用 regex 的时候,还要注意正则表达式的成本。因为正则串只有在运行时才会处理,
检查语法、编译成正则对象的代价很高,所以尽量不要反复创建正则对象,能重用就重用。
在使用循环的时候更要特别注意,一定要把正则提到循环体外。

 12 | 三分天下的容器:恰当选择,事半功倍

容器,就是能够“容纳”“存放”元素的一些数据结构。

 容器的通用特性

你必须要知道所有容器都具有的一个基本特性:它保存元素采用的是“值”(value)语义,也就是说,容器里存储的是元素的拷贝、副本,而不是引用。
从这个基本特性可以得出一个推论,容器操作元素的很大一块成本就是值的拷贝

解决办法:
1. 一个解决办法是,尽量为元素实现移动构造和移动赋值函数,在加入容器的时候使用
std::move() 来“转移”,减少元素复制的成本:

Point p; // 一个拷贝成本很高的对象
v.push_back(p); // 存储对象,拷贝构造,成本很高
v.push_back(std::move(p)); // 定义转移构造后就可以转移存储,降低成本

2. 你也可以使用 C++11 为容器新增加的 emplace 操作函数,它可以“就地”构造元素,免去了构造后再拷贝、转移的成本,不但高效,而且用起来也很方便

3. 当然,你可能还会想到在容器里存放元素的指针,来间接保存元素,但我不建议采用这种方案。
虽然指针的开销很低,但因为它是“间接”持有,就不能利用容器自动销毁元素的特性了,你必须要自己手动管理元素的生命周期,麻烦而且非常容易出错,有内存泄漏的隐患。如果真的有这种需求,可以考虑使用智能指针 unique_ptr/shared_ptr,让它们帮你自动管理元素。
一般情况下,shared_ptr 是一个更好的选择,它的共享语义与容器的值语义基本一致。使用 unique_ptr 就要当心,它不能被拷贝,只能被转移,用起来就比较“微妙”。

容器分类
常见的一种分类是依据元素的访问方式,分成顺序容器、有序容器和无序容器三大类别

 顺序容器

连续存储的数组:
 array
array 是静态数组,大小在初始化的时候就固定
 vector
 deque
它可以在两端高效地插入删除元素
指针结构的链表:
 list
list 是双向链表,可以向前或者向后遍历,但查找效率比较低
* forward_list
forward_list,顾名思义,是单向链表,只能向前遍历,查找效率就更低了。

链表结构比起数组结构还有一个缺点,就是存储成本略高,因为必须要为每个元素附加一个或者两个的指针,指向链表的前后节点。
当 vector 的容量到达上限的时候(capacity),它会再分配一块两倍大小的新内存,然后把旧元素拷贝或者移动过去。这个操作的成本是非常大的,所以,你在使用 vector 的时候最好能够“预估”容量,使用 reserve 提前分配足够的空间,减少动态扩容的拷贝代价。
vector 的做法太“激进”,而 deque、list 的的扩容策略就“保守”多了,只会按照固定的“步长”(例如 N 个字节、一个节点)去增加容量。但在短时间内插入大量数据的时候就会频繁分配内存,效果反而不如 vector 一次分配来得好。

 有序容器

顺序容器的特点是,元素的次序是由它插入的次序而决定的,访问元素也就按照最初插入的顺序。而有序容器则不同,它的元素在插入容器后就被按照某种规则自动排序,所以是“有序”的。
C++ 的有序容器使用的是树结构,通常是红黑树——有着最好查找性能的二叉树。
 set/multiset
 map/multimap

在定义容器的时候必须要指定 key 的比较函数,解决这个问题有两种办法: 一个是重载<,另一个是自定义模板参数。

 无序容器

内部是散列表
unordered_set/unordered_multiset、unordered_map/unordered_multimap。

无序容器对 key的要求:
一是可以计算 hash值,二是能够执行相等比较操作。
第一个是因为散列表的要求,只有计算 hash 值才能放入散列表,
第二个则是因为 hash 值可能会冲突,所以当 hash 值相同时,就要比较真正的 key 值。

如果只想要单纯的集合、字典,没有排序需求,就应该用无序容器,没有比较排序的成本,它的速度就会非常快。 

我再教你一个使用这些容器的小技巧,就是多利用类型别名,而不要“写死”容器定义。因为容器的大部分接口是相同的,所以只要变动别名定义,就能够随意改换不同的容器,对于开发、测试都非常方便。

 13 | 五花八门的算法:不要再手写for循环了

虽然算法是 STL(标准库前身)的三大要件之一(容器、算法、迭代器),也是 C++ 标准库里一个非常重要的部分,但它却没有像容器那样被大众广泛接受。

在 C++ 里,算法的地位非常高,甚至有一个专门的“算法库”。早期,它是泛型编程的示范和应用,而在 C++ 引入 lambda 表达式后,它又成了函数式编程的具体实践,所以,学习掌握算法能够很好地训练你的编程思维,帮你开辟出面向对象之外的新天地

C++ 里的算法,指的是工作在容器上的一些泛型函数,会对容器内的元素实施的各种操作。
不过要是“说白了”,算法其实并不神秘,因为所有的算法本质上都是 for 或者 while,通过循环遍历来逐个处理容器里的元素。

vector<int> v = {1,3,1,7,5}; 
auto n1 = std::count( 
    begin(v), end(v), 1 
);

int n2 = 0;
for(auto x : v) { 
    if (x == 1) {
        n2++;
    }
}
//配合lambda效果更好
auto n = std::count_if( 
    begin(v), end(v),
    [](auto x) { 
        return x > 2;
    }
);

这是追求更高层次上的抽象和封装,也是函数式编程的基本理念。

 认识迭代器

虽然刚才我说算法操作容器,但实际上它看到的并不是容器,而是指向起始位置和结束位置的迭代器,算法只能通过迭代器去“间接”访问容器以及元素,算法的能力是由迭代器决定的。

这种间接的方式有什么好处呢?
这就是泛型编程的理念,与面向对象正好相反,分离了数据和操作。算法可以不关心容器的内部结构,以一致的方式去操作元素,适用范围更广,用起来也更灵活。

可以把迭代器简单地理解为另一种形式的智能指针,只是它强调的是对数据的访问,而不是生命周期管理

 最有用的算法

 手写循环的替代品 for_each

它能够促使我们更多地以“函数式编程”来思考,使用 lambda 来封装逻辑,得到更干净、更安全的代码。

 排序

很多时候,这样做的成本比较高,比如 TopN、中位数、最大最小值等,我们只关心一部分数据,如果你用 sort(),就相当于“杀鸡用牛刀”,是一种浪费。

1. 要求排序后仍然保持元素的相对顺序,应该用 stable_sort,它是稳定的;
2. 选出前几名(TopN),应该用 partial_sort;
3. 选出前几名,但不要求再排出名次(BestN),应该用 nth_element;
4. 中位数(Median)、百分位数(Percentile),还是用 nth_element;
5. 按照某种规则把元素划分成两组,用 partition;
6. 第一名和最后一名,用 minmax_element

如果是 list 容器,应该调用成员函数 sort(),它对链表结构做了特别的优化。
有序容器set/map 本身就已经排好序了,直接对迭代器做运算就可以得到结果。
而对无序容器,则不要调用排序算法,原因你应该不难想到(散列表结构的特殊性质,导致迭代器不满足要求、元素无法交换位置)。

 查找算法

 binary_search    它只返回一个 bool 值,告知元素是否存在
 lower_bound      返回第一个“大于或等于”值的迭代器,判断是否找到:一个是迭代器是否有效,另一个是迭代器的值是不是要找的值。
* upper_bound,  返回的是第一个“大于”值的迭代器
begin < x <= lower_bound < upper_bound < end

 find   find_if  查找算法,找到第一个出现的位置
 search

对于有序容器 set/map,就不需要调用这三个算法了,它们有等价的成员函数 find/lower_bound/upper_bound,效果是一样的。

因为标准算法的名字实在是太普通、太常见了,所以建议你一定要显式写出“std::”名字空间限定,这样看起来更加醒目,也避免了无意的名字冲突。

 14 | 十面埋伏的并发:多线程真的很难吗?

“读而不写”就不会有数据竞争。

 多线程开发实践

 仅调用一次

程序免不了要初始化数据,这在多线程里却是一个不大不小的麻烦。因为线程并发,如果没有某种同步手段来控制,会导致初始化函数多次运行。
C++ 提供了“仅调用一次”的功能,可以很轻松地解决这个问题

    static once_flag flag;

    auto f = []()
    {
        cout << "tid=" <<
            this_thread::get_id() << endl;


        std::call_once(flag,
            [](){
                cout << "only once" << endl;
            }
        );
    };

    thread t1(f);
    thread t2(f);

    t1.join();
    t2.join();

 线程局部存储(thread local storage)

这个功能在 C++ 里由关键字 thread_local 实现,它是一个和 static、extern 同级的变量存储说明,有 thread_local 标记的变量在每个线程里都会有一个独立的副本,是“线程独占”的,所以就不会有竞争读写的问题。   
linux下的有__thread关键字

    thread_local int n = 0;

    auto f = [&](int x)
    {
        n += x;


        cout << n;    //在程序执行后,我们可以看到,两个线程分别输出了 10 和 20,互不干扰。
        cout << ", tid=" <<
            this_thread::get_id() << endl;
    };


    thread t1(f, 10);
    thread t2(f, 20);


    t1.join();
    t2.join();

和 call_once() 一样,thread_local 也很容易使用。但它的应用场合不是那么显而易见的,这要求你对线程的共享数据有清楚的认识,区分出独占的那部分,消除多线程对变量的并发访问

 原子变量

那么,对于那些非独占、必须共享的数据,该怎么办呢?
对于小数据,应该采用“原子化”这个更好的方案。
所谓原子(atomic),在多线程领域里的意思就是不可分的。操作要么完成,要么未完成,不能被任何外部操作打断,总是有一个确定的、完整的状态。所以也就不会存在竞争读写的问题,不需要使用互斥量来同步,成本也就更低。
目前,C++ 只能让一些最基本的类型原子化,
和普通变量的区别是,原子变量禁用了拷贝构造函数,所以在初始化的时候不能用“=”的赋值形式,只能用圆括号或者花括号。
最基本的用法是把原子变量当作线程安全的全局计数器或者标志位,这也算是“初心”吧。
但它还有一个更重要的应用领域,就是实现高效的无锁数据结构(lock-free)。
但我强烈不建议你自己尝试去写无锁数据结构,因为无锁编程的难度比使用互斥量更高,可能会掉到各种难以察觉的“坑”(例如 ABA)里,最好还是用现成的库。
遗憾的是,标准库在这方面帮不了你,虽然网上可以找到不少开源的无锁数据结构,但经过实际检验的不多,我个人觉得你可以考虑 boost.lock_free。

 线程

    static atomic_flag flag {false};
    static atomic_int n;


    auto f = [&]()
    {
        auto value = flag.test_and_set();

        if (value) {
            cout << "flag has been set." << endl;
        } else {
            cout << "set flag by " <<
                this_thread::get_id() << endl;
        }

        n += 100;

        this_thread::sleep_for(n.load() * 10ms);
        cout << n << endl;
    };

    thread t1(f);
    thread t2(f);

    t1.join();
    t2.join();

但还是基于那个原则,我建议你不要直接使用 thread 这个“原始”的线程概念(因为抽象层次太低了),最好把它隐藏到底层,因为看不到的线程才是好线程

具体的做法是调用函数 async(),它的含义是异步运行一个任务,隐含的动作是启动一个线程去执行,但不绝对保证立即启动(也可以在第一个参数传递 launch::async,要求立即启动线程)。
大多数 thread 能做的事情也可以用 async() 来实现,但不会看到明显的线程:

auto task = [](auto x) // 在线程里运行的lambda表达式
{
    this_thread::sleep_for( x * 1ms); // 线程睡眠
    cout << "sleep for " << x << endl;
    return x;
};
auto f = std::async(task, 10); // 启动一个异步任务
f.wait(); // 等待任务完成
assert(f.valid()); // 确实已经完成了任务
cout << f.get() << endl; // 获取任务的执行结果

其实,这还是函数式编程的思路,在更高的抽象级别上去看待问题,异步并发多个任务,让底层去自动管理线程,要比我们自己手动控制更好(比如内部使用线程池或者其他机制)。
async() 会返回一个 future 变量,可以认为是代表了执行结果的“期货”,如果任务有返回值,就可以用成员函数 get() 获取。
不过要特别注意,get() 只能调一次,再次获取结果会发生错误,抛出异常   std::future_error
另外,这里还有一个很隐蔽的“坑”,如果你不显式获取 async() 的返回值(即 future 对象),它就会同步阻塞直至任务完成(由于临时对象的析构函数),于是“async”就变成了“sync”。
所以,即使我们不关心返回值,也总要用 auto 来配合 async(),避免同步阻塞

C++20 正式加入了协程(关键字 co_wait/co_yield/co_return)。它是用户态的线程,没有系统级线程那么多的麻烦事,使
用它就可以写出开销更低、性能更高的并发程序。

 15 | 序列化:简单通用的数据交换格式有哪些?

序列化,就是把内存里“活的对象”转换成静止的字节序列,便于存储和网络传输;而反序
列化则是反向操作,从静止的字节序列重新构建出内存里可用的对象
 JSON
JSON 格式注重的是方便易用,在性能上没有太大的优势,所以一般选择
JSON 来交换数据,通常都不会太在意性能(不然肯定会改换其他格式了),还是自己用着顺手最重要。
这里介绍的json类库为:JSON for Modern C++ 
 MessagePack
它也是一种轻量级的数据交换格式,与 JSON 的不同之处在于它不是纯文本,而是二进制。所以 MessagePack 就比 JSON 更小巧,处理起来更快,不过也就没有 JSON 那么直
观、易读、好修改了。
MessagePack 支持几乎所有的编程语言,你可以在官网上找到它的 C++ 实现。
我常用的是官方库 msgpack-c,

 JSON 是纯文本,容易阅读,方便编辑,适用性最广; 
 MessagePack 是二进制,小巧高效,在开源界接受程度比较高; 
* ProtoBuffer 是工业级的数据格式,注重安全和性能,多用在大公司的商业产品里。

问:为什么要有序列化和反序列化,直接 memcpy 内存数据行不行呢?
直接memcpy,同一种语言不同机器,或者不同语言可能存在兼容问题(变量内存存储布局、编码可能不同),而Json是一种标准,由Json库处理编码问题(比如大小端),且不同语言间统一

 16 | 网络通信:我不想写原生Socket

 libcurl:高可移植、功能丰富的通信库

libcurl 使用纯 C 语言开发,兼容性、可移植性非常好,基于 C 接口可以很容易写出各种语言的封装,所以 Python、PHP 等语言都有 libcurl 相关的库。
libcurl 的接口可以粗略地分成两大类:easy 系列和 multi 系列。其中,easy 系列是同步调用,比较简单;multi 系列是异步的多线程调用,比较复杂。通常情况下,我们用 easy系列就足够了。
使用 libcurl 发送HTTP请求的基本步骤有 4 个:
1. 使用 curl_easy_init() 创建一个句柄,类型是 CURL*。但我们完全没有必要关心句柄的
类型,直接用 auto 推导就行。
2. 使用 curl_easy_setopt() 设置请求的各种参数,比如请求方法、URL、header/body 数
据、超时、回调函数等。这是最关键的操作。
3. 使用 curl_easy_perform() 发送数据,返回的数据会由回调函数处理。 
4. 使用 curl_easy_cleanup() 清理句柄相关的资源,结束会话

因为 libcurl 是 C 语言实现的,所以回调函数必须是函数指针。不过,C++11 允许你写lambda 表达式,这利用了一个特别规定:无捕获的 lambda 表达式可以显式转换成一个函数指针

 cpr:更现代、更易用的通信库

cpr 是对 libcurl 的一个 C++11 封装,使用了很多现代 C++ 的高级特性,对外的接口模仿了 Python 的 requests 库,非常简单易用。

 17 | 脚本语言:搭建高性能的混合系统

 Python

Python 本身就有 C 接口,可以用 C 语言编写扩展模块,把一些低效耗时的功能改用 C 实现,有的时候,会把整体性能提升几倍甚至几十倍。
使用纯 C 语言写扩展模块非常麻烦,那么,能不能利用 C++ 的那些高级特性来简化这部分的工作呢?
pybind11 借鉴了“前辈”Boost.Python,能够在 C++ 和 Python 之间自由转换,任意翻译两者的语言要素,比如把 C++ 的 vector 转换为 Python 的列表,把 Python 的元组转换为 C++ 的 tuple,既可以在 C++ 里调用 Python 脚本,也可以在 Python 里调用 C++的函数、类。

 lua

标准的 Lua使用解释器运行,速度虽然很快,但和 C/C++ 比起来还是有
差距的。所以,你还可以选择另一个兼容的项目:LuaJIT 
它使用了 JIT(Just in time)技术,能够把 Lua 代码即时编译成机器码,速度几乎可以媲美原生 C/C++ 代码。
不过,LuaJIT 也有一个问题,它是一个个人项目,更新比较慢,最新的 2.1.0-beta3 已经是三年前的事情了。所以,我推荐你改用它的一个非官方分支:OpenResty-LuaJIT 。它由 OpenResty 负责维护,非常活跃,修复了很多小错误。

使用 LuaBridge 可以导出 C++ 的函数、类,但直接用 LuaJIT 的 ffi 库更好;
使用 LuaBridge 也可以很容易地执行 Lua 脚本、调用 Lua 函数,让 Lua 跑在 C++里。

 18 | 性能分析:找出程序的瓶颈

性能分析的关键就是测量,用数据说话。没有实际数据的支撑,优化根本无从谈起,即使做了,也只能是漫无目的的“不成熟优化”,即使成功了,也只是“瞎猫碰上死耗子”而已。
性能分析的范围非常广,可以从 CPU 利用率、内存占用率、网络吞吐量、系统延迟等许多维度来评估。

 pstack

pstack 可以打印出进程的调用栈信息,有点像是给正在运行的进程拍了个快照,你能看到某个时刻的进程里调用的函数和关系,对进程的运行有个初步的印象。
不过,pstack 显示的只是进程的一个“静态截面”,信息量还是有点少,而 strace 可以显示出进程的正在运行的系统调用,实时查看进程与系统内核交换了哪些信息:

 perf

perf 可以说是 pstack 和 strace 的“高级版”,它按照固定的频率去“采样”,相当于连续执行多次的 pstack,然后再统计函数的调用次数,算出百分比。只要采样的频率足够大,把这些“瞬时截面”组合在一起,就可以得到进程运行时的可信数据,比较全面地描述出 CPU 使用情况。
我常用的 perf 命令是“perf top -K -p xxx”,按 CPU 使用率排序,只看用户空间的调用,这样很容易就能找出最耗费 CPU 的函数。

 源码级工具

top、pstack、strace 和 perf 属于非侵入式的分析工具,不需要修改源码,就可以在软件的外部观察、收集数据。它们虽然方便易用,但毕竟是“隔岸观火”,还是不能非常细致地分析软件,效果不是太理想。
所以,我们还需要有侵入式的分析工具,在源码里埋点,直接写特别的性能分析代码。这样针对性更强,能够有目的地对系统的某个模块做精细化分析,拿到更准确、更详细的数据。
其实,这种做法你并不陌生,比如计时器、计数器、关键节点打印日志,等等,只是通常并没有上升到性能分析的高度,手法比较“原始”。
在这里,我要推荐一个专业的源码级性能分析工具:Google Performance Tools,一般简称为 gperftools。它是一个 C++ 工具集,里面包含了几个专门的性能分析工具(还有一个高效的内存分配器 tcmalloc),分析效果直观、友好、易理解,被广泛地应用于很多系统,经过了充分的实际验证。
gperftools 的性能分析工具有 CPUProfiler 和 HeapProfiler 两种,用来分析 CPU 和内存。不过,如果你听从我的建议,总是使用智能指针、标准容器,不使用 new/delete,就完全可以不用关心 HeapProfiler。
CPUProfiler 的原理和 perf 差不多,也是按频率采样,默认是每秒 100 次(100Hz),也就是每 10 毫秒采样一次程序的函数调用情况。
它的用法也比较简单,只需要在源码里添加三个函数:
 ProfilerStart(),开始性能分析,把数据存入指定的文件里;
 ProfilerRegisterThread(),允许对线程做性能分析;
* ProfilerStop(),停止性能分析。

所以,你只要把想做性能分析的代码“夹”在这三个函数之间就行,运行起来后,gperftools 就会自动产生分析数据。

 19 | 设计模式(上):C++与设计模式有啥关系?

设计模式系统地描述了一些软件开发中的常见问题、应用场景和对应的解决方案,给出了专家级别的设计思路和指导原则。
按照设计模式去创建面向对象的系统,就像是由专家来“手把手”教你,不能说绝对是“最优解”,但至少是“次优解”。
而且,在应用设计模式的过程中,你还可以从中亲身体会这些经过实际证明的成功经验,潜移默化地影响你自己思考问题的方式,从长远来看,学习和应用设计模式能够提高你的面向对象设计水平。

经典的《设计模式》一书里面介绍了 23 个模式,并依据设计目的把它们分成了三大类:1.创建型模式、2.结构型模式和3.行为模式。
这三类模式分别对应了开发面向对象系统的三个关键问题:如何创建对象、如何组合对象,以及如何处理对象之间的动态通信和职责分配。解决了这三大问题,软件系统的“架子”也就基本上搭出来了。

 学习、理解设计原则,才能用好多范式的 C++

最常用有 5 个原则,也就是常说的“SOLID”。
1. SRP,单一职责(Single ResponsibilityPrinciple); 更常见的说法就是“高内聚低耦合”
2. OCP,开闭(Open Closed Principle); “对扩展开放,对修改关闭”
3. LSP,里氏替换(Liskov Substitution Principle);
4. ISP,接口隔离(Interface-Segregation Principle);
5. DIP,依赖反转,有的时候也叫依赖倒置(Dependency Inversion Principle)

 20 | 设计模式(下):C++是怎么应用设计模式的?

 轻松话题(一) | 4本值得一读再读的经典好书

 设计模式:可复用面向对象软件的基础
 C++标准库(第2版)   译者: 侯捷
 C++ 语言的设计与演化
 C++ Primer

个人认为,C++ 最大的优点是与 C 兼容,最大的缺点也是与 C 兼容。
一方面,它是 C 之外唯一成熟可靠的系统级编程语言(目前 Rust 还没有达到可以和C++“叫板”的程度),大部分用 C 的地方都能用 C++ 替代,这就让它拥有了广阔的应用天地。而面向对象、泛型等编程范式,又比 C 能够更好地组织代码,提高抽象层次,管理复杂的软件项目。
但另一方面,为了保持与 C 兼容,C++ 的改革和发展也被“束缚了手脚”,做出任何新设计时,都要考虑是否会对 C 代码造成潜在的破坏。这就使得很多 C++ 新特性要么是“一拖再拖”,要么是“半成品”,要么是“古里古怪”,最后导致 C++ 变得有些不伦不类,丢掉了编程语言本应该的简洁、纯粹。