先看一段C++初学者都会写的代码

1
2
3
4
5
6
7
8
9

#include <iostream>
#include <string>

int main(int argc, const char * argv[]) {
    std::string str = "Hello, World!\n";
    std::cout << str;   // 1
    std::cout << "Hello, World!\n"; // 2
    return 0;
}

试着回答下面几个问题：

• 如果之前学过其他语言但是没接触过C++，代码中<<的写法看起来很怪异，它是怎么工作的？
• 1 & 2 的写法有什么不同？它们调用的是同一个方法么？

回答

C++中有一个神奇的东西叫做操作符重载，这个操作允许用户针对某一些需要的类型自定义操作符。比如说下面这个数据类型就重载了+号操作符，从而允许更加简单的代码书写形式。这里先不讨论操作符重载带来的问题，但是这个确实是在标准库中被普遍使用的，这里看到的<<也是属于操作符重载。

1
2
3
4
5
6
7
8

class Data
{
public:
    Data& operator+(int i){std::cout << "Data+" << i; return *this;}
};

Data d;
d = d + 1;

我们可以在<ostream>中看到basic_ostream预定义了很多对于operator<<的操作符重载，可以简单的看一下，这里只摘录了一些，头文件中实际定义了更多类型。

1
2
3
4
5
6
7
8
9

// 27.7.2.6 Formatted output:
basic_ostream& operator<<(basic_ostream& (*pf)(basic_ostream&));
basic_ostream& operator<<(basic_ios<charT, traits>& (*pf)(basic_ios<charT,traits>&));
basic_ostream& operator<<(ios_base& (*pf)(ios_base&));
basic_ostream& operator<<(bool n);
basic_ostream& operator<<(short n);
basic_ostream& operator<<(unsigned short n);
basic_ostream& operator<<(int n);
...

那么1和2是否都调用了basic_ostream中预定的<<呢？2确实是调用了basic_ostream中的方法，2的代码可以改写成下面这种形式。

1
2
3

std::cout << "Hello, World!\n";
// 相当于
std::cout.operator<<("Hello, World!\n");

但1并不是调用basic_ostream中的方法。basic_ostream中预定义的都是系统自带的类型，而std::string则是标准库自定义的类型，basic_ostream并不知道它的存在。那么std::cout << str;这行代码是怎么工作的呢？

我这里先给出答案，然后在慢慢的解释是如何工作的

1
2
3
4
5

std::string str = "Hello, World!\n";
std::cout << str;
// 相当于
operator<<(std::cout, str);
//

Argument-Dependent Lookup(实参相关的查找)

中文翻译参考自C++ Primer，下面简称ADL。这个查找规则简单的可以归纳为：

当我们给函数传递一个类类型的对象时，出了在常规的作用域查找外还会查找实参类所属的命名空间。这个规则对于传递类的引用或指针的调用同样有效。 - 《C++ Primer 5th》

举个例子就能够很直观的看到这个效果。

1
2
3
4
5
6
7
8
9
10

namespace NS 
{
   class A {};
   void f( A &a, int i) {}
}
int main() 
{
   NS::A a;
   f( a, 0 );    //calls NS::f
}

有了这个规则以后我们就很好理解本文开头的第一个例子如何工作的。<string>头文件中定一个一个operator<<的操作符重载并且接受basic_ostream为第一个参数，std::string为第二个参数。当编译器在basic_ostream中找不到对应的函数的时候，它便开始在std::string的命名空间下查找对应的方法。然后它找到中有一个符合要求的方法，然后就调用了这个方法。关于C++的命名查找规则是一个巨复杂的东西，有兴趣可以看看这个页面（Name Lookup）

同理，我们可以为我们自己的类型自定义这个操作符重载，这样我们在输出的时候就可以更加的方便。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

class Person
{
public:
    std::string name;
    int age;
};

std::ostream& operator<<(std::ostream& os,
                         const Person &p)
{
    os << "name: " << p.name << " age: " << p.age;
    return os;
}

Person p{"john", 100};
std::cout << p << std::endl;

关于ADL我们需要注意什么

能够被ADL找到的非成员方法应该被视为类的设计的一部分，如果你考虑写类似的方法如果不是为了ADL的话应该避免这种写法。

ADL能够极大的方便我们编码时候的方法调用，从而提高代码的可读性。STL库内使用的swap方法也广泛的使用了这个技术。关于swap的话题，改天单独讨论。

参考资料

• Stackoverflow - What is “Argument-Dependent Lookup” (aka ADL, or “Koenig Lookup”)?
• GotW #30 - Name Lookup Herb Sutter
• Argument-dependent name lookup wikipedia
  -

这章就是介绍如何设计你的并发代码、在写并发代码的时候需要考虑的一些因素和注意的地方。从一个更高的角度去思考如何写并发代码。

如何给线程分配工作

当我们起多个线程去做并行计算的时候我们需要把原来一个线程处理的数据分配给不同的线程。那么如何切分数据就有很多种选择：

简单粗暴的根据数量切分

比如有100个数据，我们起了m个线程那么每个线程处理100/m个数据。如果有必要的话最后将处理的结果进行合并。打个比方，我们现在要洗n个碗，那么我们可以把线程想象成洗碗工，如何给洗碗工分配工作，假设每个洗碗工洗碗速度差不多，那么只需要把盘子分成若干份分配给各个洗碗工即可。（当然你要有足够多的洗碗池）

递归的切分

有很多算法无法在一开始就很好的对数据进行切分，那么我们就可以用递归的方法。但是递归的话就不能暴力的去起线程，而是可以用std::async让线程库去决定是否在另外线程执行。

按照任务类型进行切分

还是用厨房打比方，如果现在收到了一个订单需要做100份宫保鸡丁。如果按照第一种方法的话就是把100道分给n个厨师，每个厨师负责做100/n份。那么这个有什么问题呢？每个厨师都需要去洗菜、切菜、炒菜、装盘等。每一道工具之间会浪费厨师的时间，而且如果厨房不是足够大的话，厨师之间可能会出现竞争关系，比如说只有3个炒锅、那么有一些厨师可能需要排队才能用到炒锅。

现实中的厨房肯定不是这样的，每一个环节都是有专门的人负责的。洗菜工、打荷、厨师。这样流水线的工作可以提高效率。

按照任务类型的切分方法跟厨房的这个思想是一样的，每个线程都有自己的指责，接受输入处理相对独立的功能。

影响并发代码性能的因素

在说影响性能的因素之前，先来看一张表Latency Numbers Every Programmer Should Know

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

Latency Comparison Numbers
--------------------------
L1 cache reference                           0.5 ns
Branch mispredict                            5   ns
L2 cache reference                           7   ns                      14x L1 cache
Mutex lock/unlock                           25   ns
Main memory reference                      100   ns                      20x L2 cache, 200x L1 cache
Compress 1K bytes with Zippy             3,000   ns        3 us
Send 1K bytes over 1 Gbps network       10,000   ns       10 us
Read 4K randomly from SSD*             150,000   ns      150 us          ~1GB/sec SSD
Read 1 MB sequentially from memory     250,000   ns      250 us
Round trip within same datacenter      500,000   ns      500 us
Read 1 MB sequentially from SSD*     1,000,000   ns    1,000 us    1 ms  ~1GB/sec SSD, 4X memory
Disk seek                           10,000,000   ns   10,000 us   10 ms  20x datacenter roundtrip
Read 1 MB sequentially from disk    20,000,000   ns   20,000 us   20 ms  80x memory, 20X SSD
Send packet CA->Netherlands->CA    150,000,000   ns  150,000 us  150 ms

计算机的计算发生在CPU，而数据则来自内存、磁盘甚至网络上。从上表可以看到，CPU访问的数据来源对于它的访问速度差距巨大。从最快的L1缓存到网络访问，差距有3亿倍之巨。

下面要说的几点，基本上可以理解为需要经常从“很远的”读取数据。

线程数量

线程数量并非越多越好，当线程的数量太多，而且都有实际运算需要进行的时候。操作系统会进行调度来保证线程之间的公平，而切换线程的时候会出现上下文切换。也就是说要把当前线程相关的上下文存下来，然后把另一个线程的上下文载入，这回带来一定的开销。当线程数量增加的时候，带来的开销也就越来越大。

Data Contention（数据竞争）

可以理解为多个线程同时去操作一个内存，至少有一个去写这块内存。如果所有的操作都是只读的话就没有问题，因为数据从内存载入CPU以后会一直有效。但是，当其他核/CPU去操作这块内存的时候，载入的数据就会失效，当前的核就需要重新去内存中载入这块内存。

如果有多个核同时在操作某一个内存的时候，这将会是灾难性的。因为每一次写，其他所有用到这个数据的核都需要重新载入这块内存。而多个核频繁写的话，就会让用到数据的和核频繁去载入内存。而我们知道从内存读数据是很慢的。这个现象可以很形象的称为cache-pingpong。

False Sharing

CPU载入内存的时候是按照一个内存块载入的，而不是具体单个内存地址，这块内存又称为cache-line。这个机制会带来什么问题呢？如果我们需要的是一个小块数据，但是cache-line在如何很多我们不需要的数据。我们不需要不要紧，麻烦的是这些数据可能被其他线程用到而且需要修改，当他们改了这块内存以后我们就莫名的躺枪了。因为我们载入的这块cache-line失效了。

Data Proximity

如果你需要处理的数据不再同一个cache-line里面也会带来问题，就是你需要载入很多内存块去用到你的数据。

设计数据结构的时候需要注意什么

针对上面这几个可能会影响性能的地方，我们再设计数据结构的时候需要注意一下几点：

1. 给不同线程分配数据的时候要考虑他们之间的数据不要靠的太近避免false sharing。
2. 单个线程需要的数据尽量挨得近一点，从而不用去载入太多cache-line。
3. 尽量减少线程对于数据的需求。

设计多线程代码其他注意事项

异常安全

如果你起的线程有未处理的异常，程序将会退出(C++调用std::terminate)。当然你可以在线程代码内部处理掉异常，但是你需要将这个异常告诉外部从而外部能够知道错误状态来进行一些善后。

C++11里面可以用std::future的方式自然地实现这个，因为在std::future::get的时候如果线程有未处理的异常，会在调用的地方重新抛出来。

可扩展性

可扩展性的意思是当处理器数量增加的时候，程序能够在更短的时间内完成任务或者在相同时间内能够处理更多的数据。

一个程序内部可以分为两部分，一部分为串行部分，而另一部分则是可以被并行的部分。有一个Amdahl定律简单地描述了并发代码的性能，给出的公式如下：

$$ P = \dfrac{1}{f_s+\frac{1-f_s}{N}} $$

P为整体性能，$f_s$表示程序中串行的部分，N为处理器的数量。所以当试图优化代码的时候最好权衡一下优化能够带来的效益。应该让代码尽量的能够并行，这样能够充分利用好处理器增加带来的好处。另外如果串行的部分比例很大，比如说80%，那么优先去优化串行部分显然是比较划算的。

提高响应速度

在GUI应用中尽量将一些好使的操作放在非UI线程去做，这样子能够提高UI的响应速度从而提高用户体验。

C++内存模型

在谈具体的C++内存模型之前，需要先了解一下什么是重排(reordering)，以及重排会给我们带来什么样的问题。

重排主要存在于两个阶段，一个阶段是编译时，当C++代码编译成指令的时候编译器会在不影响程序的前提下对程序进行重排和优化。另一个是运行时，处理器会在对结果没有影响的情况下对指令进行重排。两个重排的目的都是为了提升性能。这两个重拍的前提都是它们认为对结果不会产生影响，这个推导在单线程的情况下是成立的。但是当这段代码涉及到多线程，情况可能就会不如你所愿。举个很简单的例子， y==42乍看之下不可能为false，但是这个是不能够100%保证的。为什么？因为重排。而重排按照以下这种写法是无法控制的。

1
2
3
4
5
6
7
8
9
10
11
12

int x = 0;
int y = 0;
// run at thread 1
void M1() {
    y = 42;           // 1
    x = 1;            // 2
}
// run at thread 2
void M2() {
    while (x!=1);     // 1
    assert(y+x==42);    // 2
}

这也就是内存模型所要解决最大的问题：对抗重排。更加具体一点，C++内存模型主要要解决的问题是：

• 对抗重排，让程序能够按照我们想要的顺序去执行，能够在任何情况下都保证结果正确，而是不靠运气；
• 上面代码除了重排以外还存在的问题就是，在访问同一块内存的时候没有加保护，而这个是会导致未定义的行为的，内存模型需要解决data race的情况下给出一套可预期的行为。

通俗版本

那么对抗重排不可能说让整个程序都不允许任何重排，这个是不可能的。准确的讲，我们其实是不想看到会影响我们预期效果的重排。拿上面那个程序举个例子，上面的M1和M2之间其实存在着某种依赖关系。当M2.1中x!=1不成立的时候，我们期望看到的是M1.1已经完成执行了，我们可以理解成M2.2依赖于M1.1的操作。

那么对抗重排的武器是什么，是fence，又叫memory barrier。我们可以在M1.2处设置一个边界，清楚地告诉编译器和处理器你们在这个边界上面乱搞可以，但是请不要跑到下面来。然后在M2.1处也设置一个边界，告诉编译器和处理器你们在这行下面乱搞可以，但是请不要跑到上面来。

既然是边界，那么就有两个方向，根据不同的规则可以定义以下四种边界：CAN_UP_CAN_DOWN(能上能下)，CAN_UP_NO_DOWN(能上不能下)，NO_UP_NO_DOWN(不能上不能下)，NO_UP_CAN_DOWN(不能上能下)。

那么我们改写一下上面的代码

1
2
3
4
5
6
7
8
9
10
11
12

// run at thread 1
void M1() {
    y = 42;           // 1
    CAN_UP_NO_DOWN
    x = 1;            // 2
}
// run at thread 2
void M2() {
    while (x!=1);     // 1
    NO_UP_CAN_DOWN
    assert(y+x==43);    // 2
}

那么对应到C++中的内存模型的话可以用下面这幅图来理解

用这种通俗的理解方法，这四种内存模型(memory_order_relaxed, memory_order_acquire, memory_order_release, memory_order_seq_cst)应该就不难理解了。还有一种比较特殊的是memory_order_consume，这个是上面第四个的一个弱化版。还是拿我们这个程序来举例，我们这个例子中M2.2其实只依赖于M1.1这一行，而不依赖于其他行的代码。所以我们只需要保证M1.1在CAN_UP_NO_DOWN以上，M2.2在NO_UP_CAN_DOWN以下就能够保证正确性了，没有必要一竿子把所有的操作都限制住。可以让更多的表达式通过fence，自由自在的优化。

专业版本

上面用我自己理解的通俗版本介绍了这几种内存模型的区别，专业版的话需要搞清楚两个概念：Happens-Before和 Synchronizes-With。推荐大家直接阅读参考资料中的两篇文章，讲得很好，以我目前的理解水平还不能够比这两篇文章更好更通俗的去解释这两个概念。读完就基本知道是怎么回事了。

C++ atomic注意事项

使用C++中的atomic有以下一些注意事项：

• 预定义的atomic类型基本都重载了常用的操作符，所以你如果用起来的话可以跟普通基础类型一样。但是默认用的memory order是最强的memory_order_seq_cst。所以你在理解memory oder的情况下应该尽可能的使用相对较弱的memory order。特别是如果你的代码可能跑在ARM等弱内存序的处理器上。
• 如果要使用一个自定义的类型扩展std::atomic ，那么这个类型必须满足一下两个条件：这个类型及其所有父类和非静态的成员都必须有trival copy-assignment操作符，简单地说就是能够用memcpy直接进行拷贝；二，必须是在字节层面能够直接比较的，可以理解为能够用memcmp进行比较

参考

• The Happens-Before Relation
• The Synchronizes-With Relation
• The Purpose of memory_order_consume in C++11

condition variables

condition variables主要是用来等待某个事件的通知，比如说线程1专门负责处理数据，线程2则是从IO读取数据放到队列里。这个时候线程1就需要等队列空闲的时候等待新的数据，而线程2则需要在数据放入队列以后通知线程1。代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

// Thread 1

std::mutex mtx;
std::queue<data> data_queue;
std::condition_variable cond;

void process_data()
{
while (true)
{
std::unique_lock<mtx> lk;
cond.wait(lk, []{return !data_queue.empty();}); // 1
auto data = data_queue.front();
data_queue.pop();
lk.unlock();                                    // 2
process(data);
if (is_last_chunk(data))
break;
}
}

void prepare_data()
{
while(more_data_to_prepare())
{
auto data = prepare_data();
std::unique_lock<mtx> lk;
data_queue.push(data);
cond.notify_one();                               // 3
}
}

这段代码有几个关键的知识点：

• 为什么#1处condition_variable wait的时候需要传一个unique_lock？
• 为什么#1处，需要判断data_queue.empty？
• #1，除了wait以外还有没有其他方式？
• 为什么#2处要显式unlock？
• #3 处是否还有其他notify的方式，并且有何区别？

为什么#1处condition_variable wait的时候需要传一个unique_lock？

第一次看到condition_variable会比较奇怪为什么需要传入一个锁。这个是因为，condition_variable需要运行pred来检查是否满足等待条件，而这个往往是需要访问共享数据的，这个锁是用来保护这段共享数据的。

这个是其中一个原因，但是你会发现有一个wait函数是不需要传入predicate的。这个时候这个lock的意义则在于保护condition_variable本身内部的信号。因为多个线程会同时访问这个condition_variable，所以需要某种机制来对其内部的数据结构进行保护。^[1]

为什么#1处，需要判断data_queue.empty？

有一种wake up叫做spurious wakeup。简单地说就是，被notify了但是其实有可能它需要等待的那个条件已经不满足了，在这个例子中就是data_queue可能在它被唤醒的时候是empty。那么为什么会出现这种情况呢？

我们可以想一下condition_variable内部是怎么实现的，下面这段伪代码

1
2
3
4
5
6
7

void
condition_variable::wait(unique_lock<mutex> &lock)
{
lock.unlock();
// some system call to wait for event
lock.lock();
}

可以看到，wait的开始的时候应该会先把把mutex给释放掉，然后等待系统事件。当收到事件以后则会再次尝试去获取mutex。可以看到在收到系统事件和获取mutex这期间是没有任何mutex做为保护的。在这个时候很有可能外部的条件已经被另外的线程给修改掉了，所以之后再次获取到mutex并不能保证一定满足所需要等待的条件。

看了一下libcxx内部的实现，它其实是直接调用了pthread的pthread_cond_wait。而在pthread_cond_wait的内部实现则不是我上面说的那么简单，还有很多其他的操作。这个具体代码我也没有完全看明白，就不在这里详述，有机会另外再研究。（我看的是glibc里面pthread的实现）。

除了wait以外还有没有其他方式？

除了wait以外还提供了wait_until和wait_for两个api，主要是用来避免等待太久。内部实现的话wait_until其实是转换成了wait_for，所以一个比较有意思的事情是如果你在等待期间去修改系统的时间的话，对于最终等待的时间是不会产生影响的，它内部开始的时候已经换算成时间差了。

1
2
3
4
5
6
7
8
9
10
11
12
13
14

std::condition_variable cv;
std::mutex mtx;
std::unique_lock<std::mutex> lk(mtx);
auto now = std::chrono::system_clock::now();
std::time_t now_c = std::chrono::system_clock::to_time_t(now);
std::cout << std::put_time(std::localtime(&now_c), "%T") << std::endl;
cv.wait_until(lk, now + std::chrono::seconds(10));
now = std::chrono::system_clock::now();
now_c = std::chrono::system_clock::to_time_t(now);
std::cout << std::put_time(std::localtime(&now_c), "%T") << std::endl;

// output:
20:57:19
20:52:27

为什么#2处要显式unlock？

拿到数据以后，data_queue已经不需要保护，而且处理数据可能会比较耗时。没有必要在这个地方去一直拿着mutex。

#3 处是否还有其他notify的方式，并且有何区别？

可以选择notify_one和notify_all，顾名思义。两个的区别是唤醒的等待线程数量不一样。notify方法调用的时候是需要去获取mutex的。

std::future

一个异步方法如何返回一个结果，C/C++程序员的第一反应应该是用回调函数。回调函数确实可以解决这个问题，但是回调函数本身也有着诸多的问题。C++11中引入lambda和闭包，能够让这个问题有所缓解。但是使用回调的方法并非一个优雅的解决方法。

举个例子

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

void CalcSomething()
{
    std::mutex mtx;
    std::condition_variable cv;
    
    int result = 0;
    doSomethingAsync(11, [&result, &cv](int r){
        result = r;
        cv.notify_one();
    });
    // Do other things
    std::unique_lock<std::mutex> lk(mtx);
    cv.wait(lk);
    // use result to do more calculation
}

看着就蛋疼。那么future就是可以帮我们解决这个问题。有了它我们可以这么写代码。

1
2
3
4
5
6
7
8

void CalcSomething()
{
    auto f = doSomethingAsync(11);
    // Do other things
    f.wait();
    int result = f.get();
    // use result to do more calculation
}

确实可以大大简化我们原来的代码，其实隐约看到另外一种编程的方法。但是在很多时候还是不够用，比如说CalcSomething也是一个异步方法，我想让结果等待以后继续做事情但不想同步的等。那么我们可以起一个线程去执行上述代码，比如

1
2
3
4
5
6
7
8
9
10
11

void CalcSomethingUseThread()
{
    std::thread t([]{
        auto f = doSomethingAsync(11);
        // Do other things
        f.wait();
        int result = f.get();
        // use result to do more calculation
        });
    t.detach();
}

但是很显然随随便便起一个线程只为做这么简单的事情未免开销太大了，而且很多项目里是有类似线程池来统一管理线程的。目前的future还不能够很好地处理这种需求，要么用独立线程运行，要么通过注册回调来做。

不过Folly::Future对std::future做了极大的扩充，提供了类似的解决方案。有兴趣的可以去了解一下。

实际运用中C++11中的std::future有点鸡肋的感觉，除非在C++20以后能够加入更加多的功能，否则并没有很大的吸引力去用这套机制。

参考

1. Stackoverflow - Why do pthreads’ condition variable functions require a mutex?
2. Jon Skeet - Does C# Monitor.Wait() suffer from spurious wakeups?

什么是内存模型

In computing, a memory model describes the interactions of threads through memory and their shared use of the data.
Wikipedia

有点抽象，似乎还是没有很好地定义出内存模型是什么，下面这段是摘自A Primer on Memory Consistency and Cache Coherence(APMCCC)¹第三章。

A memory consistency model, or, more simply, a memory model, is a specification of the allowed behavior of multithreaded programs executing with shared memory. For a multithreaded program executing with specific input data, it specifies what values dynamic loads may return and what the final state of memory is.

简单的说，内存模型可以理解为一套协议，定义多个处理器/线程在在操作内存的时候需要遵循的一套协议。什么是允许的什么是不允许的。

可以看到这里的内存模型和内存一致性模型指的是同一个概念。

内存一致性模型的很多概念可以推广到一致性模型，一致性模型则是在分布式系统中很重要的一个概念。从某一个角度来说，多(核)处理器与内存的关系也是一种分布式系统。

内存模型的分类

内存模型可以分为硬件内存模型(hardware memory model)和软件内存模型(software memory model) ³。

硬件内存模型可以理解为硬件与软件之间的一套协议(contract between the hardware and software) ²，硬件会在协议中说明会在什么情况下进行重排什么情况下不会。这里的硬件一般指的是处理器，而软件指的是操作处理器的指令。

软件内存模型可以理解为程序员和编程语言之间的一套协议(contract between programmer and programming language)，编程语言会规定一套规则来说明什么情况下会对代码进行重排，并且提供一些机制能够让程序员对一些操作进行控制。

从硬件和软件的角度是看内存模型的一个维度，另一个维度则是一致性的强度。一致性可以是强一致性也可以是弱一致性。

这张不严谨的图参考自Weak vs. Strong Memory Models，稍微做了一下变换。

大部分程序员关心的是软件维度的内存模型，即程序员和编程语言之间的协议。内存模型的强度与软硬件无管，是抽象层面的一个东西即适用于硬件也适用于软件。

在wikipedia上我们可以看到有很多不同的一致性模型分类，这里对于C++中的内存模型比较相关的是：Sequential Consistency、Release consistency。

Sequential Consistency

Sequential Consistency(SC)是最符合直觉的一种内存模型也是很关键的一种。是由Leslie Lamport在1979年提出来的。

理解这个模型有两个关键点：

1. 程序的执行顺序按照代码顺序
2. 代码中对于内存的访问不会被乱序

#1 很好理解，即执行顺序不会随意重排，尊重代码顺序。#2则不是很好实现，

上图为APMCCC中的截图。把内存操作想象成都需要通过一个开关，每次内存都挑选一个核允许其进行内存访问。这样就可以保证所有的内存访问不会被乱序。不难发现这个模型最大的问题就是同一时间只能有一个核对内存进行访问，这个很大程度上削弱了多核带来的提升。

Release consistency

在Release consistency中进入critical section(关键区)称为acquire，离开critical section称为release。Acquire操作是读操作，release是写操作。

简单的理解就是acquire操作会阻止所有在此操作以下的内存读取操作被重排到此操作前。release会保证所有操作之前的内存读取操作不会被重排到release操作后。下图可以很清晰的表达这个关系(The Purpose of memory_order_consume in C++11)：

总结

对于理解C++的内存模型，上面的这些预备知识就差不多足够了。强烈推荐阅读Preshing关于Lock-free的一系列博客，还有这本小书A Primer on Memory Consistency and Cache Coherence。

Preshing的Lock-free的系列博客，没有列全，可以顺藤摸瓜找到相关文章。

• Memory Barriers Are Like Source Control Operations
• Weak vs. Strong Memory Models
• Acquire and Release Semantics
• The Purpose of memory_order_consume in C++11

参考

1. A Primer on Memory Consistency and Cache Coherence, Daniel J. Sorin, Mark D. Hill, David A. Wood
2. Memory Consistency Models: A Primer, James Bornholt
3. Weak vs. Strong Memory Models, Jeff Preshing
4. Acquire and Release Semantics
5. “Strong” and “weak” hardware memory models

一个典型的死锁会发生在如下的场景中：

• 一段代码试图去同时独占地去获取两个共享资源（mutex或者其他）a和b，按照先a后b的顺序。
• 另一段代码试图去同时独占的去获取两个共享资源a和b，但是获取顺序是相反，先b后a。
• 这两段代码可能同时执行。

这种情况下就会出现个两个代码块互相等待对方资源的情况，造成死锁。并非所有的情况都是很明确的能看到两个获取两个资源，有可能是你占有一个资源的时候调用了其他方法，也有可能是因为一些回调函数。所以这个问题可能会隐藏的很深。

普遍的建议就是永远按照同样的顺序去获取多个锁，但是正如上面所说的有时候多个锁可能是在不同的地方获取的，并没有那么明显。

有一个方法可以破这个就是Lock Hierarchies。每一个mutex都分配一个层级号码，并且严格按照下面两个规则：

1. 当占有层级为N的mutex的时候，只能去获取层次< N的mutex
2. 当试图同时占有多个同层级的mutex的时候，这些锁必须一次性获取，通过类似于std::lock的方法去保证顺序。

Herb给了一张很形象的图来描述这个方案。

实现细节

实现一个hierarchical mutex也很简单，原理和细节如下：

• 提供一个mutex wrapper，并且在所有的地方都是用这个wrapper来进行对mutex的操作，并且能够设置一个层次号
• 在wrapper内部放一个thread local的变量currentLevel来保存当前线程的层次号并将其初始化为大于所有level的号码
• 提供一些方法，比如lock, unlock，try_lock
• lock方法只有当currentLevel大于mutex wrapper的层次号才去上锁，否则抛出异常。如果上锁，则保存currentLevel并将currentLevel设置为当前的mutex 的层次号
• unlock的时候讲currentLevel重置会原来的层次号

代码

CCIA书中给出了一个很简单的hierarchical_mutex的实现。大家可以自己看看

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

#include <mutex>
#include <stdexcept>
#include <climits>

class hierarchical_mutex
{
    std::mutex internal_mutex;
    unsigned long const hierarchy_value;
    unsigned long previous_hierarchy_value;
    static thread_local unsigned long this_thread_hierarchy_value;

    void check_for_hierarchy_violation()
    {
        if(this_thread_hierarchy_value <= hierarchy_value)
        {
            throw std::logic_error("mutex hierarchy violated");
        }
    }
    void update_hierarchy_value()
    {
        previous_hierarchy_value=this_thread_hierarchy_value;
        this_thread_hierarchy_value=hierarchy_value;
    }
public:
    explicit hierarchical_mutex(unsigned long value):
        hierarchy_value(value),
        previous_hierarchy_value(0)
    {}
    hierarchical_mutex(const hierarchical_mutex&) = delete;
    hierarchical_mutex& operator=(const hierarchical_mutex&) = delete;
    void lock()
    {
        check_for_hierarchy_violation();
        internal_mutex.lock();
        update_hierarchy_value();
    }
    void unlock()
    {
        this_thread_hierarchy_value=previous_hierarchy_value;
        internal_mutex.unlock();
    }
    bool try_lock()
    {
        check_for_hierarchy_violation();
        if(!internal_mutex.try_lock())
            return false;
        update_hierarchy_value();
        return true;
    }
};
thread_local unsigned long
    hierarchical_mutex::this_thread_hierarchy_value(ULONG_MAX);       

int main()
{
    hierarchical_mutex m1(42);
    hierarchical_mutex m2(2000);
    
}

如果所有的数据都是只读的，那么多线程之间同时访问是不会有问题的。但是如果有人要读的同时有人要改就会出现问题。因为并非所有操作都能在一步完成，一般的操作会是先去读取数据，然后做一些其他的运算或者判断，然后回写数据。那么可能发生以下一些情况：

• 但是如果多个线程同时做这个操作的话，可能某一个线程回写的时候，当时判断的逻辑已经不成立了。
• 如果两个线程同时尝试去修改同一份数据，就会出问题。
• 其他更复杂的情况

当多个线程共享内存并且去尝试修改内存里的内容的时候，就会出现race condition。这会让代码出现一些无法预料的情况。比如说：

1
2
3
4

if (x == 5)
{
y = x * 2;
}

这段代码在单线程下，如果x等于5，有一定等于10。但是如果多于一个线程运行这段代码，则y的值依赖于两个线程之间的执行顺序。如果还有一些线程在修改x的值，情况就更复杂了。

更糟糕的是在C++中，如果并发的修改同一个对象，会出现未定义的行为(undefined behavior)。

解决方案

应对race condition的解决方案有以下几种：

1. 通过某种保护机制来确保同一时间只有一个线程能够对某一个数据进行访问。
2. 通过lock-free的形式进行编程。主要指的是将对于数据的修改变成一系列不可分割的操作，C++中通常利用atomic来实现。具体会在lock-free一章中进行介绍。
3. 通过STM(software transaction memory)。这个方式是将内存的修改处理成跟数据库事务类似的机制，当修改完成commit到内存中，要么成功要么失败，不会存在中间状态。目前C++语言层面没有对这个功能的直接支持。

C++中主要使用#1和#2。#1的话主要是通过mutex为核心来实现。

利用Mutex来保护数据

Mutex是mutual exclusion（互斥）的意思。提供了lock和unlock两个方法，std::mutex同一时间值能有一个线程获得lock，当有一个线程拥有mutex的时候，其余调用lock尝试获得锁的线程会处于等待状态。

mutex本质上是一种资源，所以在C++中一般使用RAII来进行封装，避免出现lock和unlock调用不配对的情况。

C++11中提供了std::lock_guard<class Mutex>和std::unique_lock<class Mutex>封装。这两个类可以接受任何符合BasicLockable的mutex类型。

除了std::mutex以外，C++17中还提供了以下几种mutex：

• std::mutex (since C++11) 同时只能有一个线程获得锁，并且一个线程之只能lock一次。
• std::recursive_mutex (since C++11) 可重入锁，一个线程可以多次去lock同一个recursive_mutex。
• std::timed_mutex (since C++11)。在std::mutex的基础上提供了 try_lock_for和try_lock_until，允许在超时的情况下返回。
• std::recursive_timed_mutex (since C++11)。在std::recursive_mutex的基础上提供了 try_lock_for和try_lock_until，允许在超时的情况下返回。
• std::shared_mutex (since C++17)。传说中的读写锁。提供lock和shared_lock两套方法。lock即获得排他锁(exclusive lock)，shared_lock即获得共享锁(shared lock)

使用mutex时候需要注意的事情

当我们用mutex将我们需要保护的数据保护起来以后是不是就可以高枕无忧了呢？这只是“噩梦”的开始。。。。

你需要注意一下若干点：

• 不要将你保护的数据当做以引用或指针形式传入“不知名”的外部函数；
• 同样也不要将你要保护的数据作为指针或引用返回函数外部；
• 当你有多个锁要锁的时候，需要注意死锁；
• 如果你提供一个类型需要保证线程安全，确保你在设计api的时候精心考量；
• 控制锁的粒度，避免一些耗时的无必要的操作放在mutex保护范围内；

死锁

当你试图获取一个以上的锁的时候，如果姿势不对就可能产生死锁。解决死锁的通用的方法是，在所有需要同时获得多个锁的地方都按照一样的顺序去获取锁。当你需要同时获取两个锁的时候，std::lock可以帮你避免死锁的问题。

但是如果你的锁是在不同地方分别获得的，你还是有可能死锁。

关于如何避免死锁，有一些通用的建议：

• 避免在一个锁的内部嵌套另外一个锁；
• 不要在拥有一个锁的时候去调用其他方法，因为你不知道其他方法会做一些什么事情；
• 用固定的顺序去获取锁；
• 利用Lock Hierarchy，这个核心思想是保证固定顺序去获得锁。每一个锁都分配一个层次号，锁的获取顺序只能是从高层到底层。反向则不行。书中给的例子很好，值得好好去理解。
• 死锁并不一定发生在有锁的地方，任何需要等待其他线程的地方都可能发生死锁。

控制锁的粒度

In general, a lock should be held for only the minimun possible time needed to perform the required operations.

不要多、不要少、够用最好。

其他保护共享数据的方法

• static初始化。C++11开始，static初始化变量保证是线程安全的。对于一些只需要初始化一次的静态变量使用。
• 利用std::recursive来避免一些可重入的情况，但是大部分情况需要可重入的锁意味着代码设计可能有问题。最好通过调整代码来避免这种情况。
• 利用std::shared_lock来提高性能，针对大部分情况都是读，只有少数情况下会去修改的数据。

• 定义了内存模型
• <thread>，引入std::thread来管理、控制线程。
• <atomic>，原子操作相关类。
• <mutex>，引入mutex，以及相关的类，用于锁等互斥操作。
• <condition_variable>，引入condition_variable以及相关类，用于线程间同步。
• <future>，引入future, promise以及相关的一些类，主要用于线程间同步和通信的一些机制。

这篇主要介绍对于线程管理的相关话题，对书中的内容进行总结并适当扩展。

• 如何创建一个线程
• 如何销毁一个线程
• std::thread的所有权(owenership)
• 如何控制线程数量
• 线程ID

如何创建一个线程

1
2

template< class Function, class... Args > 
explicit thread( Function&& f, Args&&... args );

std::thread构造函数如上，它可以接受任何callable的类型，包括全局方法、成员方法、std::function、仿函数、lambda表达式等。并且后面可以带参数，用来传递给方法。

例子：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

void func1() {}
class A {
public:
    void func2(){}
};

struct B {
public:
    void operator()() { }
};


    A obja;
    B objb;
    A obja;
    B objb;
    std::thread t1(func1);          //全局方法
    std::thread t2(&A::func2, obja);//成员方法
    std::thread t3(objb);           //functor
    std::thread t4([](){});         //lambda

注意事项：

• std::thread对象一旦创建，线程马上就起来了，没有办法延迟启动。
• std::thread一旦起来以后没有办法通过api它杀掉，除非通过native_handle拿到平台相关的线程句柄进行操作。这个非C++提供而是操作系统提供。

传参

启动线程的时候可以传递参数，传参的形式默认为拷贝，如果有类型转换则是在线程启动时进行。所以需要保证传递的参数不依赖于方法栈上的其他内存。

如果不满足于默认的按值拷贝，可以通过std::ref或std::move进行传引用或转成右值进行move操作。下面给出几个例子。

1
2
3
4
5
6
7
8
9

void pass_by_val(int i) {}
void pass_by_ref(int &i) {}
void pass_by_move(std::unique_ptr<big_obj> bigObj){}

    int i;
    std::thread t1(pass_by_val, i);
    std::thread t2(pass_by_ref, std::ref(i));
    std::thread t3(pass_by_move, std::make_unique<big_obj>());

注意事项：

• std::ref 注意引用的生命周期和线程的生命周期的关系。

如何销毁一个线程

你没法销毁一个线程，你只能等它跑完或者让他在后台运行并且把其管理权移交给C++运行库。

下面介绍一组和线程结束相关的api：

• bool jionable()： 如果是默认线程(即std::thread t;)则是false。只要一个线程被join过一次以后则变为false，即使一个线程已经结束了，但是没有被join过，还是会返回true。
• void join()。等待线程结束运行，一个线程只能被调用一次，如果在jioinable为false的情况下调用，会直接抛出std::system_error。
• void detach()。将线程放到后台运行，并且将管理权转给C++运行库。

注意事项：

• 一个线程在析构前必须调用join或者detach来显示的处理它的生命周期，否则的话会析构时直接抛出异常。
• join本身并非线程安全，如果多个线程在没有保护的情况下同时join同一个std::thread会undefined behavior

std::thread的所有权(owenership)

No two std::thread objects may represent the same thread of execution; std::thread is not CopyConstructible or CopyAssignable, although it is MoveConstructible and MoveAssignable.
http://en.cppreference.com/w/cpp/thread/thread

std::thread 只能move不能被拷贝，所以如果想要把std::thread放进容器的话必须确保是右值。直接构造出来或者用std::move进行转换都可以。

比如下面这样：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

void calc_something(int i){ std::cout << i; }

   std::vector<std::thread> thread_vec;
   for (int i = 0 ; i < 3; i++)
   {
       std::thread t(calc_something, i);
       thread_vec.push_back(std::move(t));                   // use std::move
       thread_vec.push_back(std::thread(calc_something, i)); // 直接构建为右值
       thread_vec.emplace_back(calc_something, i);           // 用emplace_back
   }
   
   for(auto & t : thread_vec)
   {
       if (t.joinable()) t.join();
   }

如何控制线程数量

线程数量并非越多越好，数量太多会导致CPU的频繁上下文切换，反而会适得其反。std::thread::hardware_concurrency静态方法可以获得。

Returns the number of concurrent threads supported by the implementation. The value should be considered only a hint.
http://en.cppreference.com/w/cpp/thread/thread/hardware_concurrency

但是这个数量仅供参考，因为依赖于不同编译器和平台的实现。有可能会返回0，表示这个数量未定义，也就是说不知道在这个硬件上有多少个并发线程可以执行。

线程ID

通过 std::thread::id std::thraed::get_id()可以拿到一个线程的id。这个id主要的用途是用来打印log和作为关系容器的key。

1
2
3
4
5
6

std::map<std::thread::id, std::thread> thread_map;
for (int i = 0 ; i < 3; i++)
{
    std::thread t(calc_something, i);
    thread_map[t.get_id()] = std::move(t);
}

这章标题为：TCP: The Transmission Control Protocol (Preliminaries)，主要是介绍一些TCP协议要解决的问题，以及大致的设计思路。具体的技术细节要在之后的章节进行详细的阐述。

简单设计一个协议

TCP协议下层的协议都不是“可靠”的，它们不保证传输的可靠性。所以要建立一个可靠地传输协议需要克服一下几个问题：

1. 包内部的数据错误(packet bit errrors)。在传输的过程中有可能导致传输的数据中的bit有错误。
2. 丢包(packet erasure)
3. 包的顺序不对(packet reordering)。
4. 重复的包(packet duplication)。

解决1和2可以用重传的机制，发送端发送包给接收端，接收端接收到以后确认没有错误返回一个确认信息（ACK/acknowledge）。如果发送端没有及时收到确认信息，则重传直到收到确认信息。

解决3和4可以假如序列号（sequence number），这样接收端就可以直到收到的包的顺序和是否重复。

上面的两个简单地解决方案可以解决我们提到的四个问题。但是这个方案本身还有一些悬而未决和不足的地方：

1. 发送端应该等待多久才认为是超时了？（这个问题比较复杂，会在十四章详述）
2. 如果接收端发出来的ACK信息丢失了怎么办？（可以归类为第一个问题）
3. 如果接收端收到包但是有错误怎么处理？（假如checksum校验，如果发现有错误则不确认，即可归类为第一个问题）
4. 这个方案只能一个一个包发送，大部分情况下发送端处于空闲状态，效率低下。（下面会引入窗口概念）

窗口和滑动

解决上述方案中的第四个问题，我们可以引入一个窗口的概念。一次不是只发送一个包，而是发送一组包。可以想象成一个窗口，当前面发送的包已经被确认以后，则可以将窗口往下进行滑动去发送更多的包。窗口的基本意思可以看书上的插图，比较直观。

可以看到窗口的大小会直接影响到同时发出多少个包，这个大小的设置就直接影响到了接收端和中途的网络设备。如果太大的话可能会导致接收端无法处理，也可能导致中途的网络设备无法处理造成丢包，从而影响发送效率。太小的话则无法很好地充分利用网络资源和接收端的资源。

这里会引入两个概念。流量控制（flow control）和阻塞控制（congestion control）。

接收端可以根据自己的情况告诉发送端自己合适的窗口大小是多少，一般通过ACK包一起发送回去。这个属于流量控制，又称显式控制（explicit signaling）。

网络设备的拥堵情况则没有办法通过显式的控制，而是需要通过一些算法来计算出来一个比较合适的窗口大小。这个可以称为隐式控制（implicit signaling）。这个会在十五章里面详细讨论。

如何设置超时？

对于每一个包的传输时间（round-trip-time），即从发送到收到确认的时间，我们可以知道。我们能通过一些统计来估算出一个大概的时间当做超时。很显然平均值不是一个很好的选择，因为如果用平均值的话可能会有很多请求直接被超时了。如何设置超时也是一个需要深入讨论的问题，会在十四章中进行讨论。

介绍TCP

TCP协议是一个面向连接（connection-oriented）的协议，这个意思是两个应用必须先建立连接，然后才能进行通行。

TCP是一个可靠的协议，它具备以下几个特点确保其其可靠性：

• 强制checksum校验，保证数据传输是对的。如果传输的数据块太大则需要引入其他的中间层来保证。
• 有timer来保证超时会重发。
• 有ACK来保证接收端确认收到包。并且ACK的确认是累加性的，如果接收端收到了x+2 返送了ACK x+3，但ACK x+3丢了。下次接收端接收到x+3的时候会返回ACK x+4，这样就可以避免x+2重传。
• TCP有序列号来解决乱序和重复包的问题。
• TCP为全双工，两边都可以进行传输。

TCP头部和封装

插两张图

图中可以看到有8个比特位用来控制TCP的一些flag，用于不同的请求。可能会多于一个比特位被置成1。

先抛出两个问题

• 如果delete一个指针，但是它真实的类型和指针类型不一样会发生什么？
• 是谁调用了析构函数？

下面这段代码会发生什么有趣的事情？

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

// delete_diff_type.cpp
#include <iostream>

using namespace std;

class Foo
{
public:
    Foo() { cout << "Foo()" << endl; }
    ~Foo() { cout << "~Foo()" << endl; }
};

class FakeFoo
{
public:
    FakeFoo() { cout << "FakeFoo()" << endl; }
    ~FakeFoo() { cout << "~FakeFoo()" << endl; }
};

int main(int argc, const char * argv[]) {
    
    void* vptr = new Foo();
    delete vptr;    // warning
    
//    FakeFoo* ffptr = static_cast<FakeFoo*>(new Foo()); // error
    FakeFoo* ffptr = reinterpret_cast<FakeFoo*>(new Foo());
    delete ffptr;
    
    Foo* fptr = new Foo();
    delete fptr;
    
    return 0;
}

1
2
3
4
5
6

输出:
Foo()
Foo()
~FakeFoo()
Foo()
~Foo()

看一下汇编代码可以看到main函数主要做了下面这几件事

1
2
3
4
5
6
7
8
9
10
11
12
13

; symbol stub for: operator new(unsigned long)
; Foo::Foo at delete_diff_type.cpp:8
; symbol stub for: operator delete(void*)

; symbol stub for: operator new(unsigned long)
; Foo::Foo at delete_diff_type.cpp:8
; FakeFoo::~FakeFoo at delete_diff_type.cpp:16
; symbol stub for: operator delete(void*)

; symbol stub for: operator new(unsigned long)
; Foo::Foo at delete_diff_type.cpp:8
; Foo::~Foo at delete_diff_type.cpp:9
; symbol stub for: operator delete(void*)

从汇编中可以看出，构造造函数和析构函数是编译器根据指针的类型生成的调用代码。而且编译器是不允许没有继承关系的指针之间进行转换的，void* 是个例外，只要不作死用reinterpret_cast把指针转换成不相关的类型是不会有问题的。

所以上面两个问题大概就有答案了。delete语句会至少产生两个动作，一个是调用指针对应类型的析构函数，然后去调用operator delete释放内存。所以如果delete的指针和其指向的真实类型不一样的时候，编译器只会调用指针类型的析构函数，这也就为什么基类的析构函数需要声明称虚函数才能够保证delete基类指针的时候子类析构函数能够被正确的调用。
operator delete是都会被调用到的，所以指针指向的那块内存是能够“正常的”被释放掉用。

std::shared_ptr<void> 的行为

那么这个跟std::shared_ptr<void> 有什么关系呢？

先看一段代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

#include <iostream>

using namespace std;

class Foo
{
public:
    Foo() { cout << "Foo()" << endl; }
    ~Foo() { cout << "~Foo()" << endl; }
};

int main(int argc, const char * argv[]) {
    shared_ptr<void> vptr = shared_ptr<Foo>(new Foo);
    return 0;
}

1
2
3

输出：
Foo()
~Foo()

与第一段代码中类似，不过把void*换成了std::shared_ptr<void>，那么shared_ptr<void>为什么能够调用到正确的析构函数呢？一定是shared_ptr里面搞了什么鬼。

std::shared_ptr<void> 为啥能正常工作

那么就看看源代码看看到底为啥这货能够工作，下面是libcxx中shared_ptr的部分源码，把关键的部分抠出来了。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72

/** C1. shared_ptr 构造函数 **/

template<class _Tp>
template<class _Yp>
shared_ptr<_Tp>::shared_ptr(_Yp* __p,
                            typename enable_if<is_convertible<_Yp*, element_type*>::value, __nat>::type)
    : __ptr_(__p)
{
    unique_ptr<_Yp> __hold(__p);
    typedef typename __shared_ptr_default_allocator<_Yp>::type _AllocT;
    typedef __shared_ptr_pointer<_Yp*, default_delete<_Yp>, _AllocT > _CntrlBlk;
    __cntrl_ = new _CntrlBlk(__p, default_delete<_Yp>(), _AllocT());
    __hold.release();
    __enable_weak_this(__p, __p);
}

/** C2. shared_ptr 拷贝构造 **/
template<class _Tp>
inline
shared_ptr<_Tp>::shared_ptr(const shared_ptr& __r) _NOEXCEPT
    : __ptr_(__r.__ptr_),
      __cntrl_(__r.__cntrl_)
{
    if (__cntrl_)
        __cntrl_->__add_shared();
}

/** C3. shared_ptr::__cntrl_ 类型 **/
__shared_weak_count* __cntrl_;

/** C4. shared_ptr 析构函数 **/

template<class _Tp>
shared_ptr<_Tp>::~shared_ptr()
{
    if (__cntrl_)
        __cntrl_->__release_shared();
}

/** C5. __shared_weak_count::__release_shared **/

bool __release_shared() _NOEXCEPT {
    if (__libcpp_atomic_refcount_decrement(__shared_owners_) == -1) {
    __on_zero_shared();
    return true;
    }
    return false;
}

/** C6. __shared_ptr_pointer::__release_shared **/
template <class _Tp, class _Dp, class _Alloc>
/* 重点 !!! virtual !!! */
void
__shared_ptr_pointer<_Tp, _Dp, _Alloc>::__on_zero_shared() _NOEXCEPT
{
    // __data__ 是 内部工具类__compressed_pair
    // __data_.first().second()是 deleter
    // __data_.first().first() 是 shared_ptr<T> 中T类型的指针
    __data_.first().second()(__data_.first().first());
    __data_.first().second().~_Dp();
}


/** C7. default deleter **/

template <class _Tp>
struct _LIBCPP_TEMPLATE_VIS default_delete {
    // ... 此处省略若干行
  void operator()(_Tp* __ptr) const _NOEXCEPT {
    delete __ptr;
  }
};

不要慌，给你慢慢道来。

这个故事简单得说是这样的：

• 每一个shared_ptr 内部有一个control block，里面会存放一个要维护的指针，一个计数，一个删除器(deleter)，一个分配(allocator)。这里我们要关心的是删除器。顾名思义，它是用来删除指针的。
• shared_ptr中的 有一个__cntrl_即control block。字段的类型是__shared_weak_count指针，这个类是一个非模板类。shared_ptr<T>创建的control block的类型是一个类模板template <class _Tp, class _Dp, class _Alloc> __shared_ptr_pointer继承自__shared_weak_count。 见代码C3。
• 当创建一个新的shared_ptr的时候，构建一个新的control block。见代码C1。
• 当一个shared_ptr A赋值或者拷贝构造给另一个shared_ptrB的时候（当然是在类型能够转换的前提下），B会把A的__cntrl_拷一份，同时将其引用加一。注意，这个时候拷贝的是指针，__cntrl_还是指向最初创建的那个对象。见代码C2。
• 当shared_ptr被析构或者重置的时候会调用__cntrl_->__release_shared()。见代码C4。
• __cntrl_->__release_shared()如果发现当前的计数为-1的时候，调用__on_zero_shared()。见代码C5。
• __on_zero_shared是一个虚方法，那么它就会调用到最初创建的__shared_ptr_pointer的实现。
• __shared_ptr_pointer的实现中是有完整的类型和删除器的信息的。见代码C6。
• 默认的删除器很简单的执行了delete __ptr操作，因为类型是已知的所以能够正确的调用到析构函数。见代码C7。

这种实现方式给shared_ptr带来额外好处

Effective C++ 条款07告诉我们“要为多态基类声明 virtual 析构函数”。当然我认为建议依然有效，但是用了shared_ptr以后带来的一个额外好处就是即便你的析构函数忘记写成virtual也能帮你正确的调用析构函数。

这个课程主要是提供一些思路，涉及到技术的部分也只是介绍了最基本用法，并不会深入某个技术去展开。通过这个课程的学习，我们应该能够对响应式设计有一个基本的了解，能够知道在设计响应式的页面时需要如何做和需要注意的一些地方。

课程的大纲如下，比较基础，课程还有挺多的练习，通过练习能够掌握一些基本的用法。

为什么要响应式设计？(Why Responsive?)

响应式设计（Responsive Web Design，通常缩写RWD）是一种网页设计的技术，让网站在不同的设备上能够良好的显示。这个“良好的显示”是指能够给浏览网页者一个好的的体验。在移动设备普及前，一个网站只需要在一定程度上考虑不同尺寸即可，但是移动设备的普及，会引入一些很小尺寸的屏幕而且比例也不确定。这就需要响应式设计。

响应式设计除了是一门技术以外，更多的是一门艺术，如何安排在不同尺寸上的显示方式很大程度上是设计相关的东西而不是技术相关的东西。

移动优先

移动优先的设计方式是指在设计的时候从移动端先开始设计，然后再慢慢的往大尺寸去增强。这样的设计方式能够帮助设计者更好的去思考对于一个网页来说什么是最重要的内容，如何把这些内容合理的摆放才能达到效果。

从小开始（Starting Small）

既然涉及到不同的设备，那么关于尺寸的一些概念就需要在这里先搞清楚。

• 设备分辨率（Hardware Resolution/Pixel）
• 设备独立像素（Device Independent Pixel）
• CSS像素（CSS Pixel）
• Viewport

设备分辨率

这个很好理解，指得是设备本身的实际分辨率，也就是说一个设备上事实上分布的像素点的个数。

设备独立像素

设备独立像素是基于某一个系统的坐标系中的一个物理度量单位，系统会将设备独立的像素转换成设备上的实际像素。^[1]

举个例子，iPhone 3G和iPhone 4S的物理尺寸都是3.5英寸，它们的设备分辨率分别是320 x 480和640 x 960。但是它们的设备独立分辨率是一样的，都是320 x 480^[2][3]。

课程中给出了一个很形象的图

CSS像素

在浏览器没有缩放的情况下，1个CSS像素对应1个设备独立像素。

Viewport

Viewport指的是用户在设备上的可视区域，在移动设备上这个可视区域往往比网页上的区域小。所以在老的移动浏览器上，会把页面根据实际的大小渲染出来，如果那个尺寸比手机大，用户则需要通过移动，放大和缩小来进行操作。

移动版Safari引入了“viewport meta”标签来允许开发控制viewpoint的尺寸和缩放比例，虽然这个不是标准，但是大多数的浏览器目前支持这种做法。

典型的viewport的使用方法如下，将这个meta标签加到<head>中：

1

<meta name="viewport" content="width=device-width, initial-scale=1">

关于Viewport的内容还有很多，我会另起一篇文章进行深入的学习。

从“小”开始

这里的从“小”开始指的是从小屏幕开始设计开发，这个跟上面提到的移动优先的概念是吻合的。

作者给出了两个图来解释，我觉得挺形象的。从小到大设计和从大到小设计就如同图中的漏斗一样。从大到小，很可能会误把一些有用的内容给过滤掉，而从小到大则不会。

另外从小开始设计还能够一开始就考虑到性能相关的问题。

逐步构建（Building Up）

构建一个响应式的引用主要需要用到一下几个概念和技术：

• Media Query
• Breakpoint
• Flexbox

Media Query

Media query 是实现响应式编程使用的最重要的技术，这个是在CSS中根据某一些条件包含一些样式。

1
2
3
4
5
6
7

@media screen and (min-width: 480px) {
    body {
        background-color: lightgreen;
    }
}
Try it Yourself »
The

这个是media query的语法定义，举个例子，比如我们想在viewport大于400px时将背景颜色改成红色。

1
2
3
4
5

@media screen and (min-width: 400px) {
    body {
        background-color: red;
    }
}

Breakpoint

使用了media query以后会存在一个或多个点是的某一些样式被引用进来，比如上面的那个media query中400px就称为一个breakpoint（断点）。

断点的设置也是根据设计而来，没有严格的要求。我们可以在一个断点进行大的UI调整，也可以在断点进行一些细微的调整。这个也是一门艺术，而不是一个技术。

视频中提到了两个断点的例子，我觉得可以仔细观察一下：

• http://skinnyties.com/
• http://cnn.com

Flexbox

Flexbox是flexible box的缩写，是2009年W3C提出了一种新的布局解决方案。目前已经在所有的浏览器上得到支持^[5]。Flex
布局的核心思想是让flex容器有能力去修改其子元素的宽度，高度还有顺序从而更好的使用可用的空间。

课程中提到的不同响应式设计的模式都是使用flex技术实现的。

Common Responsive Patterns

课程中提供了四种比较通用的响应式模式，这几种模式只是提供了一种思路。可以根据具体的设计组合使用。

Column Drop

Mostly Fluid

Layout Shifter

Off Canvas

Optimizations

课程提供了几个在响应式设计的时候可以注意的优化点，包括图片、字体和表格。

图片

响应式的图片，不仅仅是要求图片的尺寸要正确，最关键的是要保证在不同的尺寸下图片显示出来的主体是一个合理的而不是只显示了一部分或者以不合理的缩放比例展示出来。在另一门「Responsive Images」有关于响应式图片的深入介绍。

字体

在适当的时候需要调整字体的大小从而使其能够更好地适应当前的尺寸。
另外，一行的字数也要控制在一个合理的而范围之内，就英语而言，每行65个字符是比较合适的

表格

表格在尺寸的屏幕上比较尴尬，因为表格的信息量比较大而且往往有比较多的列。对于表格我们可以采用一些策略：

• 减少表格列，只显示最重要的信息。
• 将列展平，用行的形式显示列。
• 将表格放在一个container，将container的样式设置为overflow-x: auto, width: 100%。将滚动的区域控制在一个小范围内。

References

[1]: Wikipedia - Device-independent pixel
[2]: Apple iPhone 4s vs Apple iPhone 3G
[3]: Viewport Sizes
[4]: Mozilla - Using the viewport meta tag to control layout on mobile browsers
[5]: Can I use Flexbox

某天晚上，在家附近吃完晚饭，突发奇想往从来都有去过的街的另一头散步走去。走出不到两公里，惊奇的发现原来离我家这么近的地方竟然还有一处迷你的公园。突然心生感慨，其实很多美好的东西可能就在你附近，只是你一直被一个隐形的边界限定住了你探索的脚步。

有一种说法是“旅游就是从一个你熟悉的地方跑到你一个别人熟悉的地方”。为什么有人喜欢旅游？因为在一个陌生的地方，人们往往能够发现一些不一样的地方，你去的地方离你越远可能这种差异性更强，能够给你带来的冲击也就越强。反过来，其他地方的人到你所生活的地方也同样会受到类似的冲击。在一个陌生的地方，人们的各个感官都处在兴奋、焦虑的状态，它们会极力得去吸取尽可能多的信息然后在脑子里飞速的运算。走在一个异国的路上，可能路边的一个垃圾桶、一个流浪汉、一个普通的招牌都能够吸引你驻足去观察，因为你从来没见过这样的东西。但如果，你在这个地方待上一段时间，你会发现你变得跟本地人一样，把自己的“感官”关闭了，不再抱有极大的好奇心去观察周遭的事物。因为你养成了习惯，习惯可以让你省去很多的思考，让你很轻松的去完成一件事情。比如说，你从地铁站出来不用思考是往左走还是往右走，你的习惯会把你很自然的带回家。

旅游只是一个简单的例子，除了旅游以外我们的生活中还有非常多的类似的例子。我认为在几乎所有你做的事情上，这种现象都是存在的。小到刷牙洗脸，大到公司决策，都或多或少的收到习惯的影响。

我们的大脑很聪明也很懒，它帮我们养成了很多的习惯，这样我们就不需要处处进行思考，很多时候跟着熟悉的感觉就能够完成一件事情了。大脑的聪明是很有必要的，在多数情况下能够让我们变得更轻松。但是，这种聪明也为我们设立了一个无形的边界，一个我们不留意可能都不会去注意到的一个边界。在这个边界内，我们是”安全”的，因为某些路径已经被多次证明过是可行的。

然而一条“安全”可行的路径不代表这条路径是最优的，即使在当下是最优的，也不代表它在外部条件变化的情况下依然是最优的。所以说这种安全是不可靠的，因为外界的条件不可能永远不变。而且习惯是有一定的惯性的，一个习惯你坚持的越久它的惯性就越大，你要改变它的难度及所带来的痛苦也就越大。

所以，我的结论是要需要经常去「界外」看看，让我们拥有随时改变路径的能力。

那么这个结论就引出了另外几个问题：

1. 作为一个身处于边界里面的人如何去发现自己的边界。都说要Think out of box，但是如何才能够发现自己的box？
2. 发现以后到外面看看，肯定不能是简单地看看就完了。如何保持一个开放的心态去看待界外的事物？
3. 如何才能够拓宽自己的边界？

这几个问题，容我再想想。

条款18：让接口容易被使用，不易被误用

• 好的借口很容易被正确使用，不容易被误用。你应该在你的所有接口中努力达成这些性质。
• “促进正确使用”的办法包括接口的一致性，以及与内置类型的行为兼容。
• “阻止误用”的办法包括建立新类型、限制类型上的操作，束缚对象值，以及消除客户的资源管理责任。
• std::shared_ptr支持定制型删除器（custom deleter）。可防范DLL问题，可被用来自动解除互斥锁等等。

这个条款的思想其实适用于所有的编程语言，只要你写的代码需要被其他地方调用，你都需要考虑接口的易用性。即使不暴露，良好的接口设计也能够提高代码的可读性。作者提出的这几点只是在C++这个语言的基础上需要注意的一些小点，我认为设计一个良好的易用的接口，仅仅做到这几点还远远不够。

接口一致性

作者认为除非有充分的理由，否则最好让类型与内置的类型的行为尽量一致。这个可以降低使用者错误使用的概率。

我想补充的另外一点是，比如你提供一整套的接口，你需要让自己的接口相互保持一致的风格。包括但不仅限于：函数的命名风格、函数的行为尽量保持统一的风格。

防止误用

任何接口如果要求客户必须记得做某件事情，就是有着“不正确使用”的倾向，因为客户可能会忘记做那件事。

条款19：设计class犹如设计type

Class 的设计就是type的设计。在定义一个新type之前，确保阅读了本条目的所有讨论主题。

• 新type的对象应该如何被创建和销毁？ 这个涉及到构造函数、构造函数以及operator new, operator delete, operator new[], operator delete[]。
• 对象的初始化和对象的赋值该有什么样的差别？这个主要是要考虑构造函数和赋值操作符的行为。
• 新type的对象如果被passed by value，意味着什么？
• 什么事新type的“合法值”？这点主要是要注意类型的成员变量和合法性检查。
• 你的新type需要配合某个继承图系吗？如果你继承其他的类，需要考虑它们的函数virtual和non-virtual性。如果你的类可能被继承就需要注意你声明的函数——尤其是析构函数。
• 你的新type需要什么样的转换？如果你的类型需要转换成其他的类型，需要考虑定义显式转换或者隐式转换的函数。
• 什么样的操作符和函数对此新type而言是合理的？参考条款23，24，26.
• 谁该取用新type的成员？这个可以使用者的角度来帮助你判断哪一些成员为public，哪个为protected。
• 你的新type有多么一般化（generic）？如果很一般化，可以考虑设计一个class template。
• 你真的需要一个新type吧？如果只是定义新的derived class以便为既有的class添加功能，那么说不定单纯定义一个或多个non-member函数或template更能够达到目标。

这些问题并不是那么容易回答，在设计一个类型的时候尽量的去考虑这些问题能够更好地设计出一个易用合理的类型。

条款20：宁以 pass-by-reference-to-const 替换 pass-by-value

• 尽量以pass-by-reference-to-const 替换 pass-by-value。前者通常比较搞笑，并可以避免切割问题（slicing problem）。
• 以上规则并不适用于内置类型，以及STL的迭代器和函数对象。对于它们而言，pass-by-value往往比较适当。

C++默认的传递对象的方法是by-value的方式，当一个对象有很多的成员变量或者有很深的继承结构。那么对于这个对象的构造和销毁会带来很大的开销。这种情况下用pass by reference的方式就能够节省下这种开始。加上const是避免对传入的参数进行修改。

Pass by value的另一个问题就是对象切割的问题。如果一个子类对象以pass-by-value的形式传递到一个函数中来，那么它的对象将会被切割而失去子类特有的成员变量，而且同时也会失去多态性。pass-by-reference可以解决这个问题，因为reference往往以指针实现，所以截断对象也同时会保有多态性。

决定一个对象pass by value还是pass by reference的依据不是简单地类型的成员数量，还要考虑这个类型在拷贝的时候是否会做一些比较昂贵的操作。

有一些例外，即内置类型，以及STL的迭代器和函数对象。除此之外 pass-by-reference-to-const 优于 pass-by-value。

条款21：必须返回对象是，别妄想返回其reference

• 绝不要返回pointer或reference指向一个local stack对象，或返回reference指向一个heap-allocated对象，或返回pointer或reference指向一个local static对象而有可能同时需要多个这样的对象。

返回一个pointer或者reference指向一个local stack对象明显是不合理的，因为local stack的生命周期在函数返回的时候就已经结束了，那么返回的那个指针或者引用将会指向一块被销毁的对象的内存。

指向一个heap-allocated的对象也是不合理的，因为你把销毁对象的任务移交给了使用函数的人，很多情况下人们会忘记。或者说所写的代码并没有让他有机会去销毁这个对象。比如说：

1
2
3
4
5
6
7
8

const Rational& operator * (const Rational& lhs,
const Rational& rhs) {
...
return *result;
}

Rational w, x, y, z;
w = x * y * z;

只有在类似于单例的情况下，返回一个reference指向一个static的对象是合理的。比如说条款4中FileSystem的例子。

条款22：将成员变量声明为private

• 切记将成员变量声明为private，这可赋予客户访问数据的一致性、可细微划分访问控制、允诺约束条件获得保证，并提供class作者以充分的实现弹性。
• protected 并不比public更具封装性。

为什么public不好？

public的成员变量破坏了类的封装性，它将成员直接暴露给客户，那么在未来修改字段的时候就会影响到使用者。

为什么protected也不好？

有一个原则，即某些东西的封装性与“其内容改变时可能造成的代码破坏量”成反比。如果从这个原则出发的话，protected虽然比public好，但是也并没有好太多。因为如果说你这个类型是对外暴露的，你不能阻止用户继承你这个类型，然后去访问其中的成员变量（C++暂时没有类似于final class的概念）。所以说protected的成员变量也不好。

条款10：令 operator= 返回一个 reference to *this

• 令赋值（assignment）操作符返回一个 reference to *this。

有以下两个主要原因：

1. 允许连锁赋值。比如说，int x, y, z; x = y = z;
2. 这个协议被普遍的遵守（包括标准库中的很多类型），为了保持类的行为与其他类一致性。

条款11：在operator=中处理“自我赋值”

• 确保当对象自我赋值时operator=有良好行为。其中技术包括比较“来源对象”和“目标对象”的地址、精心周到的语句顺序、以及copy-and-swap。
• 确定任何函数如果操作一个以上的对象，而其中多个对象是同一个对象时，其行为为仍然正确。

一个对象可能被自我赋值，比如：

1
2
3

Widget w[];
// some operation
w[i] = w[j];//w[i]和w[j]指向同一个对象

可以在operator= 操作中做一下简单的指针比较来避免不必要的操作

1
2
3
4

Widget& Widget::operator=(const Widget& rhs) {
    if (this == &rhs) return *this;
    ...
}

当你需要在赋值操作中做一些复杂的控制逻辑，你不仅需要保证起“自我赋值安全性”还要保证“异常安全性”。这个会在条款xx中具体进行说明。

条款12：复制对象时勿忘其每一个成分

• Copying 函数应该确保复制“对象内的所有成员变量”及“所有base class成分”
• 不要尝试以某个copying函数实现另一个copying函数。应该将共同机能放进第三个函数中，并由两个copying函数共同调用。

copy构造函数和copy assignment操作符我们统称为copying函数。当我们自己定义copying务必要确保所有的字段都进行了复制，同事如果有基类要保证相对应的copying函数被正确得调用。

作者认为虽然说copy构造函数和copy assignment操作符做的操作绝大多数是相同的，但是不应该尝试以某一个copying函数实现调用另一个copying函数。这样的操作并不合理。

3. 资源管理

条款13： 以对象管理资源

• 为防止资源泄露，请使用RAII对象，它们在构造函数中获得资源并在析构函数中释放资源。
• 两个常被使用的RAII classes分别是tr1::shared_ptr和auto_ptr(C++ 11 中有std::shared_ptr和std::auto_ptr)

内存泄漏和资源泄露很多情况都是因为一个内存/资源分配在堆上，被用于一个函数内，然后在控制流离开函数的时候没有得到正确的释放。对于这种情况引起的资源泄露，可以把资源包装成对象来实现合理的释放。

“以对象管理资源” 通常也被称为”资源取得时机便是初始化时机”（Resource Acquisition Is Initialization: RAII）。RAII的两个核心思想：

• 获得资源后立刻放进管理对象内。
• 管理对象运用析构函数确保资源得到释放。

我们可以根据自己的需求定制RAII类，同时也可以使用系统提供的智能指针可以用来作为管理对象。

• auto_ptr - auto_ptr被销毁时会自动删除它所指之物。它的缺点是，如果多个auto_ptr指向同一个对象，那么那个对象会被删除一次以上。另外通过copy构造函数或copy assignment操作符复制它们的时候，它们会变成null。
• shared_ptr - shared_ptr是一个引用计数原理的智能指针。它能够持续追踪有多少个对象指向某个资源，而且它的复制行为也看上去正常许多。它的缺点是，它无法打破循环引用的问题。

条款14：在资源管理类中小心copying行为

• 复制RAII对象必须一并复制它所管理的资源，所以资源的copying行为决定RAII对象的copying行为。
• 普遍而常见的RAII class copying行为是：禁止copying、施行引用计数法（reference counting）。不过其他行为也都可能被实现。

当我们定制RAII对象的时候，需要根据具体的需求来控制其拷贝的行为。不然可能会出现一些“不愉快”的事情。

拷贝的行为基本有下面几种：

• 禁止复制。 很多情况对RAII对象进行复制是不合理的，比如说一个Lock类，保存着一个锁。合理的行为是禁止这个类型的复制行为。

• 对底层资源祭出“引用计数法”。 如果我们希望保有资源，知道它的最后一个使用者被销毁。这种情况我们就应该在内部使用一个引用计数来管理资源，我们可以用shared_ptr来做引用计数。

• 复制底部资源。 拷贝时将内部的资源进行一个完整的深层拷贝。比如说，一个字符串被复制的时候，它不仅要复制指向内存中字符串的指针，同时也应该复制对应的字符串内存。

• 转移底层资源的拥有权 在一些比较特殊的场合可能希望只有一个RAII对象指向一个资源，当被复制的时候，资源的拥有权将会进行转移。这个行为跟auto_ptr的行为是一样的。

条款15：在资源管理类中提供对原始资源的访问

• APIs 往往要求访问原始资源（raw resources），所以每一个RAII classes应该提供一个“取得其所管理之资源”的办法。
• 对原始资源的访问可能经由显式转换或隐式转换。一般而言显示转换比较安全，但是隐式转换对客户比较方便。

在一些情况下我们的需要访问资源管理类中的原始资源，这个时候我们就应该提供一个能够获得原始资源的方法。

这个看上去破坏了封装性，但是资源管理类设计的初衷是为了更好地管理资源的申请和释放，并非对资源进行完全的封装。所以提供获取原始资源的方法也还是比较合理的做法。

可以通过显式和隐式转换两种方法。

显式转换

1
2
3
4
5
6

class Font {
public:
    ...
    FontHandle get() const { return f; }
    ...
}

隐式转换

1
2
3
4
5
6

class Font {
public:
    ...
    operator FontHandle() const { return f; }
    ...
}

虽然两种方式都可行，但个人认为显式的这种方式更好一些。因为这个可以避免很多不小心进行的转换，只有在需要的时候进行显式的调用。

条款16：成对使用new和delete时要采用相同形式

如果你在new表达式中使用[]，必须在相对应的delete表达式中也使用[]。如果你在new表达式中不使用[]，一定不要在相对应的delete表达式中使用[]

条款17：以独立语句将newed对象置入智能指针

以独立语句将newed对象存储于智能指针内。如果不这么做，一旦异常被抛出，有可能导致难以察觉的资源泄露。

例子：

1
2
3
4
5
6
7
8
9

int priority();
void processWidget(std::shared_ptr<Widget> pw, int p);

// Bad
processWidget(std::shared_ptr<Widget>(new Widget), priority());

// Good
std::shared_ptr<Widget> pw(new Widget)
processWidget(pw, priority());

为什么第一个例子有问题？因为在C++编译器生成代码的时候有可能会出现以下这种情况：

1. 执行”new Widget”
2. 调用priority()
3. 调用std::shared_ptr构造函数

如果第二部抛出异常，那么第一步申请出来的资源还未放入智能指针内，所以没有人去释放它。于是就造成了资源泄露。

条款05：了解C++默默编写并调用哪些函数

编译器可以暗自为class创建default构造函数、copy构造函数、copy assignment操作符，以及析构函数。

定义一个啥也没有的类：

1

class Empty { }

编译器有可能会帮你生成：

1
2
3
4
5
6
7

class Empty {
public:
  Empty() {...}     //默认构造函数
  Empty(const Empty& rhs) {...} //拷贝构造函数
  ~Empty(){...}     //析构函数
  Empty& operator=(const Empty& rhs) {...} // copy assignment操作符
}

是否生成这些方法取决于使用的时候是否需要，比如下面这段代码就用到了这些函数

1
2
3
4

Empty e1;//默认构造函数
//析构函数
Empty e2(e1);//拷贝构造函数
e2 = e1;//copy assignment操作符

条款06：若不想使用编译器自动生成的函数，就该明确拒绝

• 为驳回编译器自动（暗自）提供的机能，可将相应的成员函数声明为private并且不予实现。使用像Uncopyable这样的base class也是一种做法。

正如条款5中提到的，即使你自己没有显示定义，编译器默认会为我们创建一些函数。而在某一些条件下，这些函数所带来的行为并不是你想要的。

那么这个时候你就应该把你想要隐藏的方法声明为private并不提供任何的定义，这样任何尝试去使用的人都会收到一个链接错误。

什么的场景下可能需要使用这种方法？

• private 构造函数
  当你希望用户不能够随意的自己去创建实例而是通过某种方法获得一个实例的时候。比如说单例模式。
• private 析构函数
  当你希望一个实例的生命周期由另一个类来管理的时候使用。比如说，你需要你的实例使用引用计数，如果不是0则不能够析构。这个时候你就需要提供比如说：Acquire，Release的方法。我觉得如果只是reference count的话，利用shared_ptr也能够实现类似的功能。
  参考链接：Private Destructors
• private 拷贝构造函数和copy assignment 操作符
  当你希望一个对象是不可拷贝的时候。
  Example:

  1 2 3 4 5 6

  Class Uncopyable { ... private: Uncopyable(const Uncopyable&); ~Uncopyable& operator=(const Uncopyable&); }

条款07：为多态基类声明virtual析构函数

• polymoriphic（带多态性质的）base classes应该声明一个virtual析构函数。如果class带有任何virtual函数，它就应该拥有一个virtual析构函数
• Classes的设计目的如果不是作为base classes使用，或者不是为了具备多态性（polymorphically），就不该声明virtual析构函数。

为什么带有多态性质的基类应该声明一个virtual析构函数？

带有多态性质的基类意味着一个基类的指针可能存放着子类的实例。在这种情况下如果析构函数没有声明为virtual的话，delete一个基类指针不能够正确的调用到子类的析构函数。这就意味着会造成资源的泄露。

但是如果一个类设计的时候没有想让别的类继承，如果另一个类继承了，就可能会出现资源的泄露。因为C++在语言层面没有提供类似于C# seal的语法，所以没有办法杜绝这种情况。如果发现一个类的析构函数不是virtual的那么就不应该去继承它。

反过来看就更简单了，如果一个类设计的目的不是作为基类使用，也就意味着它的指针不可能指向一个子类的对象。那么声明成virtual的就没有太大必要，反而会因为virtual而增长了这个对象的内存大小。

条款08：别让异常逃离析构函数

• 析构函数绝对不要吐出异常。如果一个被析构函数调用的函数可能抛出异常，析构函数应该捕捉任何异常，然后吞下它们（不传播）或者结束程序。
• 如果客户需要对某个操作函数运行期间抛出的异常做出反应，那么class应该提供一个普通函数（而非在析构函数中）执行该操作。

为什么析构函数中抛出异常不好？

1. 析构函数被调用的地方不好控制，而且不好对其进行处理。因为任何对象都有析构函数，你不可能在任何地方对异常进行捕捉。（自己补充的）
2. 如果析构函数中所抛出异常未处理会导致未定义行为。

所以如果在析构函数中有可能执行到一些会抛异常的方法，需要对其进行捕捉。如果你认为异常可以忍受则默默吞下，记下log，否则记下log然后直接结束程序。

有什么更好的办法？

如果在析构函数里需要进行某个可能抛出异常的方法，那么就应该提供一个普通方法允许用户自己调用。这样子用户就有机会自己对其进行处理。

例子：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

class DBConn {
public:
   ~DBConn() {
     db.close();   //bad, may throw exception
   }
private:
  DBConnection db;
}

class DBConn {
public:
   void close() {
     db.close();
     closed = true;
   }
   ~DBConn() {
     if (!closed) {
       try {
     db.close();   //good, catch exception and provide normal method to close
   }
   catch (...) {
   //log
   }
     }
   }
private:
  DBConnection db;
}

• 为内置型对象进行手工初始化，因为C++不保证初始化它们。
• 构造函数最好使用成员初值列（member initialization list），而不是在构造函数本体内使用赋值操作（assignment）。初值列列出的成员变量，起排序次序应该和它们在class中的声明次序相同。
• 为了免除“跨编译单元之初始化次序”问题，请以local static对象替换non-local static对象。

内置对象指的是C++自带的类似于int，double的类型。这些类型变量如果没有进行初始化，其值是未定义的，如果对其进行读取会导致不明确的行为（undefined behavior）。所以必须要保证读取内置对象前，其被初始化过。

1
2

int x; // bad code
int x = 0; // good code

对于非内置类型，初始化的任务则是由构造函数负责的。包括STL库里的一些类。

1
2
3

std::string str;//it's ok
std::string str = ""; //it's also ok
Class1 obj;

类成员变量初始化 vs 赋值

类的成员变量在进入构造函数之前已经已经被初始化，所以如果在构造函数内进行”初始化“的的话其实是进行赋值，会带来额外的开销。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

class Entry {
public:
Entry();
private:
std::string name;
int value;
}

Entry::Entry() {
name = "default"; //
value = 0;        // not good 
}

Entry::Entry()
  : name("default")
  , value(0)

至于作者提到的初值列中的顺序需要与class内变量声明的顺序保持一致是因为c++总是按照class内变量声明的顺序对变量，所以为了避免带来迷惑以及容易检查是否漏掉变量未初始化，最好将初值列顺序与class内变量声明顺序保持一致。

non-local static 对象的初始化

不同编译单元内定义的non-local static对象初始化次序未定义。

编译单元

编译单元是指产出单一目标文件（object file）的那些源码，基本上是它的源文件加上其所含入的头文件。

non-local static 对象

除了定义在函数内的static变量，其他的static变量均是non-local static对象，包括global对象、定义域namespace作用域内的对象、class内的、文件作用域内的static对象。

次序未定义会导致一个问题，就是如果你需要在一个编译单元内使用另一个编译单元的静态变量，则很有可能你在调用的时候其还没有初始化。这种情况你可以通过使用返回一个local static变量的reference的方法来得到，这个方法就是单例的常见使用场景。

1
2
3
4

FileSystem &tfs() {
   static FileSystem fs;
   return &fs
}

但这个还有一个问题就是static在多线程的情况下会出现不确定性，所以最好在程序启动时先以单线程的方式调用一遍。

总之，non-local static对象最好只在一个编译单元内使用，如果需要跨编译单元使用，则使用单的方法替代。

条款01：视C++为一个语言联邦

• C++ 高效编程守则是状况而变化，取决于你使用C++的哪一个部分。

C++并不是一个单一范式编程语言，它同时支持过程形式（procedural），面向对象设计（object-oriented）、函数形式（functional）、泛型形式（generic），元编程形式（meta-programming）。

所以作者认为并不是每一个规则都是适用于所有的这些范式的，那么我们可以将C++语言分为一下几种次语言：

• C
• Object-Oriented C++
• Template C++
• STL

条款02：尽量以const，enum，inline替换#define

• 对于单纯常量，最好以const对象或enums替换#define
• 对于形似函数的宏（macros），最好改用inline函数替换#define

#define的缺点：

1. define 定义的值无法被编译器和调试器看到，出问题了很麻烦。
2. 没有良好的封装新，不能控制作用域。

const

使用const我可以这样声明一个常量：

1
2

const std::string ProductName("Mango Game");
const double Pi = 3.1415;

还可以声明一个类的专属常量：

1
2
3
4
5
6
7
8
9

//Header
class Game {
private:
static const int MaxGamePlayer ;
...
};

//cpp file
const int Game::MaxGamePlayer = 5;

enum hack

如果需要编译时使用到常量就需要enum hack这个技巧，实现如下：

1
2
3
4
5

class GamePlayer {
private:
    enum { NumTurns = 5}
    int scores[NumTruns];
};

inline function

有一些宏长得很像函数，这种宏有类型安全问题和不可预料行为两个问题。可以使用inline function来替代。

1
2
3
4
5
6
7
8
9

//这个MAX宏很不好，会出现奇怪的一些问题且无法调试
#define MAX(a,b) ((a) > (b) ? (a) : (b))

//Good
template<typename T>
inline T Max(const T& a, const T& b)
{
    return (a > b ? a : b);
}

条款3：尽可能使用const

• 将某些东西声明为const可帮助编译器侦测出错误用法。const可被施加于任何作用域内的对象、函数参数、函数返回类型、成员函数本体。
• 编译器强制实施bitwise constness，但你编写程序时应该使用“概念上的常量性”（conceptual constness）。
• 当const和non-const成员函数有着实质等价的实现时，令non-const版本调用const版本可避免代码重复。

const提供一种语义上的约束，它能够约束变量使用者的行为。当它作用于针、智能指针、迭代器上的时候可以指向指针本身也可以是指针指向物。作者提出了一个识别的技巧：如果关键字const出现在星号左边，表示被指物是常量；如果出现在星号右边，表示指针本身是常量。

例子：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

char greeting[] = "Hello"
char *p = greeting;//non const point, const data
const char * p = greeting;//non const point, const data 
char const * p = greeting;//non const point, const data
char * const p = greeting;//const point, non const data
const char* const p = greeting; //const point, const data

const std::vector<int>::iterator it;// --> T * const p
*it = 10; //合法
it++;//不合法
std::vector<int>::const_iterator it;// --> const T * p
it = 10;//不合法
it++;//合法

std::shared<T> p1;
std::shared<const T> p;// --> const T *p
p = p1;//合法
*p.get() = x;//不合法
const std::shared<T> p; // --> T* const p
p = p1;//不合法
*p.get() = x;//合法

有点头晕，我有一个不是很恰当地记忆方法。可以把const看成修饰它右边所有内容的，以const char* p为例，把p看成一个指针，而*p则是数据，所以const是修饰数据的。而char * const p中，const右边只有p，所以它只是限制指针本身的。

bitwise constness vs logical constness

当限制一个成员函数为const，编译器会执行bitwise constness，即检查函数内部是否修改了类的成员变量。但是写代码的时候应该注意逻辑上的常量限制，比如说一个你返回了一个指向内部变量的指针，这个函数虽然符合编译器的const限制但却不是很好的一个写法。

[to be continued]

grep是linux中常用的文本处理的工具，与之类似的工具有sed和awk，它们分别适用于不同的场景。同时要想很好的使用grep等文本处理工具，需要对正则表达式有一定的了解。

grep vs sed vs awk

grep主要用于对文本、文件进行搜索，查找出符合要求的字符串并输出相关的内容。

sed和awk则是更强大文本处理工具，适用于更复杂的场景。sed是一个基于字符流的处理工具（stream editor），不仅可以查找文字还可以对文本进行操作，比如说修改、删除、插入等。awk则是更加强大的工具，它本身是一个完整的编程语言，可用于对数据的提取处理然后生成一些报表，主要针对类csv格式的文件。

正则表达式

to be written

grep的种类

• grep | grep使用简单的模式和正则表达式进行搜索。
• egrep | egrep使用拓展版的正则表达式，包含更多的正则表达式功能。
• fgrep | fgrep是加速版的grep，主要适用于简单的模式匹配。
• zgrep, zegrep, zfgrep | 与grep, egrep, fgrep 效果相同，只是可以接受一个由compress或gzip压缩出来的压缩包进行搜索。在现在的操作系统中，多种的grep使用的是同一个binary，而不是不同的binary。比如说grep -E其实等效于egrep，grep -F等效于fgrep。

常用参数

-A num, --after-context=num - 打印出找到的匹配行后num行。这个跟-B，-C类似功能，主要用于查看上下文。

-B num, --before-context=num - 打印出找到的匹配行前num行。

-C[num, --context=num] - 打印出找到的匹配行前后num行，相当于-A num -B num。

-c, --count - 统计出匹配的总行数，同一行有两个匹配也只算一行。

--colour=[when, --color=[when]] - 将匹配的字符标记为彩色，when可以是’never’，‘auto’或’always’。

-e pattern, --regexp=pattern - 制定在搜索中使用的匹配模式，多用于指定多个匹配模式的情况。

-H - 在每一行前面打印出匹配的文件名，在多个文件的情况下这个是默认选项。

-h - 在多个文件的情况下不打印出匹配的文件名。

-n - 打印出匹配所在行的行数。

-i, --ignore-case - 查找时忽略大小写。

-R, -r, --recursive - 递归的去查找子目录下的文件。

-v, --invert-match - 打印出不匹配的行。

-w, --word-regexp - 只匹配整个单词。

案例学习

实验文件，随便找了一个莎士比亚的十四行诗：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

$ cat demofile
sonnet 18

Shall I compare thee to a summer's day? 
Thou art more lovely and more temperate: 
Rough winds do shake the darling buds of May, 
And summer's lease hath all too short a date: 

Sometime too hot the eye of heaven shines, 
And often is his gold complexion dimm'd; 
And every fair from fair sometime declines, 
By chance or nature's changing course untrimm'd 

But thy eternal summer shall not fade 
Nor lose possession of that fair thou owest; 
Nor shall Death brag thou wander'st in his shade, 
When in eternal lines to time thou growest: 

So long as men can breathe or eyes can see, 
So long lives this and this gives life to thee.
$ cp demofile demofile2

1. 在文件中搜索某个字符串。

   1 2 3 4

   $ grep "and" demofile Thou art more lovely and more temperate: Nor shall Death brag thou wander'st in his shade, So long lives this and this gives life to thee.

2. 匹配整个单词。

   上面的例子中搜索and这个字符串匹配了wander这个单词，如果我们只想搜and这个单词可以使用-w参数。

   1 2 3

   $ grep -w "and" demofile Thou art more lovely and more temperate: So long lives this and this gives life to thee.

3. 忽略大小写

   1 2 3 4 5 6

   $ grep -i -w "and" demofile Thou art more lovely and more temperate: And summer's lease hath all too short a date: And often is his gold complexion dimm'd; And every fair from fair sometime declines, So long lives this and this gives life to thee.

4. 使用正则表达式

   只要把匹配的字符串换成需要的正则表达式即可。比如说需要搜索以And开头的行。

   1 2 3 4

   $ grep "^And" demofile And summer's lease hath all too short a date: And often is his gold complexion dimm'd; And every fair from fair sometime declines,

5. 显示上下文

   有时候搜出来需要看看上下文，可以利用上面提到的-B，-A和-C来实现。

   比如想要找出包含”nature”的句子并打印出上下两行。

   1 2 3 4 5 6

   $ grep -C2 "nature" demofile And often is his gold complexion dimm'd; And every fair from fair sometime declines, By chance or nature's changing course untrimm'd But thy eternal summer shall not fade

6. 统计出匹配的总行数

   比如说想要统计出现”to”的行数

   1 2	$ grep -c "to" demofile 5

   如果想要统计出现的总次数的话，grep本身没有办法满足这个需求，需要使用sed或awk来实现。或者结合wc来实现。

   1 2	$ grep -o "to" demofile| wc -l 5

7. 高亮匹配文字

   高亮匹配文字可以让肉眼可以第一时间的看到匹配结果，利用–color=auto/always来实现。此处nature高亮状。

   1 2	$ grep --color=auto "nature" demofile By chance or nature's changing course untrimm'd

8. 简单匹配多个模式

   查找多个字符串可以使用|字符来进行简单的匹配。比如说"heaven|nature"表示匹配heaven或者nature。因为这个是正则表达式的拓展部分，所以需要使用-E或者egrep。

   1 2 3

   $ grep -E "heaven|nature" demofile Sometime too hot the eye of heaven shines, By chance or nature's changing course untrimm'd

9. 复杂匹配多个模式

   需要找出符合多个模式的匹配。比如说，找出以”When”开头或者包含”fade”的行。

   1 2 3

   $ grep -e "^When" -e "fade" demofile But thy eternal summer shall not fade When in eternal lines to time thou growest:

10. 找出不满足条件的匹配

    在一些情况下我们需要找出不满足某个条件的行，这个时候就可以用-v来实现了。

    比如说想找出首字母不是大写字母的行。

    1 2	$ grep -v "^[A-Z]" demofile sonnet 18

11. 打印出匹配所在行的行数

    1 2 3

    $ grep -e "^When" -e "fade" -n demofile 13:But thy eternal summer shall not fade 16:When in eternal lines to time thou growest:

12. 打印出文件名

    进行多个文件搜索的情况下，默认会打印出文件名。

    1 2 3 4 5

    $ grep -e "^When" -e "fade" demofile demofile2 demofile:But thy eternal summer shall not fade demofile:When in eternal lines to time thou growest: demofile2:But thy eternal summer shall not fade demofile2:When in eternal lines to time thou growest:

[EOF]

mv是用于移动文件的命令，mac下没有重命名的命令，所以很多时候mv也用来重命名文件。

常用参数

-f - 强制覆盖不提醒
-i - 覆盖目标文件前提醒
-n - 不覆盖目标文件

将n个文件移动到某个目录下

mv file1 file2 file3 dir

如果目录不存在，会报错

重命名/移动文件

mv file1 file2

如果file2不存在则重命名为file2，如果存在则覆盖

移动目录

mv dir1 dir2

将dir1移动到dir2目录下，如果dir2不存在则是一个重命名的效果

rm（remove）

此命令用于删除文件和目录，与通配符结合使用时破坏很大，稍有不慎将酿成大错后悔莫及。

普通的删除只是将文件从文件系统中移除，磁盘上的那块空间并不会去动它。所以如果误删除的话，通过某一些还原工具是有可能找回来的。

Linux并没有撤销删除命令，一旦你用rm命令将某个文件删除，你将很难恢复（mac可以通过特殊的数据还原工具）。如果错误的使用rm，特别是跟通配符结合使用的时候，将有可能造成极大的危害。
在rm中使用通配符之前，有一个有用的小诀窍：先将你的通配符用ls命令试试看，看一下所影响的文件。当你用ls测试过没问题以后，你可以直接把ls特换成rm。^[1]

基本用法

rm [-dfiPRrvW] file ...

-f - 强制删除，没有提示
-i - 删除某个文件前请求确认
-P - 粉碎性删除。删除文件前重新复写整个文件，往文件里不停写入0xff和0x00。这样删除的文件无法恢复。
-R - 递归删除。如果指定的文件为目录，则删除目录下所有的文件及其子目录。

rmdir（remove directory）

不要被这货的名字迷惑了，这个命令唯一的用途就是删除一个空白的文件夹。如果文件夹非空还是要用rm -r来删除，不知道它存在的意义是什么。

mkdir（make directory）

顾名思义，创建文件夹使用。

基本用法

-p 创建中间目录，比如mkdir /path/with/many/layer会帮你吧layer之前的所有层级的目录都创建出来。
-m 制定文件夹的权限，详见chmod。

参考资料

1. Manipulating Files

阅读更多

在ls命令中有出现过一个-O的选项，即列出文件的file flag。这个File flag所为何物？

File flag是在BSD Unix中的概念，跟Linux系统中的attr是差不多的一个概念，是文件的一些标志位来存放文件的某些属性。chflags就是来修改这个file flag的。这个文件属性是跟文件系统相关的，所以这个命令在不同的文件系统上的支持程度不一样，体现在某一些flag在一些特定的文件系统上没有。^[1]

所有的属性都可以被超级管理员修改，有一些可以被文件的所有者修改。以下列出比较常用的几个属性^[1]。

基本用法

chflags [-fhv] [-R [-H | -L | -P]] flags file

常用参数

-R 递归修改参数中文件夹下面的所有文件和文件夹的属性

具体案例

为一个文件添加一个属性

chflags uchg file

为一个文件删除一个属性

chflags nouchg file

在属性名字前面添加no就可以将属性删除，如果这个属性本身已no开头（比如nodump）则去掉no。

将文件夹及其文件夹下所有文件属性进行修改

chflags -R uchg directory

参考资料

1. chattr - Wikipedia