在之前的文章中我实现了 SharedPtr，而为了实现 UniquePtr 我阅读了一些文章[1]，意识到我之前的实现存在了大量的问题。正如文章作者所言，智能指针的实现并不适合作为学习材料，它看上去很简单，却存在着大量的陷阱。而 Boost 库的实现直到其成为 C++ 11 的标准，大概有九年的时间。 不过既然开了坑，姑且硬着头皮写下去吧，毕竟也算作学习的一个过程。 先给出代码： 12345678

其实 boost 库已经有相关的实现，在实际工程中使用 boost 库的实现可能会使得我们程序更加健壮。 这边展示的是一个比较 naive 的实现，逻辑上也并不复杂。 成员变量readerCount记录正在临界区的读者数量，mutexReader以及mutexWriter实现相应的控制逻辑 WLock和WUnlock比较简单，就是直接对mutexWriter进行加锁和放锁 而在RLock中，首先会

成员变量cap_记录了容量大小，而size_则记录了实际存储的元素的数量，iniVal作为const值表示MyVector对象创建时为其预分配的容量大小，vector则是指针，其指向的应该是对象数组的起始地址 12345private: T *vector = nullptr; size_t cap_; size_t size_; const int iniVal = 20

前言回望最初版本的shared_ptr，其实存在着很多问题，比如没有考虑 Constructor Failure以及未使用 copy-and-swap idiom来解决 code duplicate 等. 在这里我打算保留最初的版本，并添加说明对此进行更正 Old Version成员变量ptr用于保存共享的指针，而 refCount则是计数器，在这里注意 refCount是指针，这样的话可以做到多

本文讲述了 BoundedBuffer 的 C++ 实现，而 BoundedBuffer 常常用于生产者和消费者模式中 在 boost 库的 circular_buffer文档中讲述了如何使用 circular_buffer来构建BoundedBuffer[1],我基于 boost 库的例子做了个改写，代码如下 1234567891011121314151617181920212223242526

其实这来自于 《Effective C++》 Rule 09： Never call virtual functions during construction or destruction 这一点主要是因为构造函数和析构函数比较特殊 12345678910111213141516171819202122232425262728#include &

本文比对了 KMP 以及 C++ string 的find方法在检查 a 是否为 b 子串这一问题上的效率。 尽管字符串长度已经达到了 104 这一量级，但是在 test case 数量为 105 时，KMP 表现仍没有find好. 首先，毫无疑问，从时间复杂度上分析，KMP 确实胜于 find的暴力匹配，但是 KMP 会在 build next table 上花费比较多的时间，在字符串长度仍

讲 https 的文章其实已经挺多了，在这里不赘述了，可以参考 Cloudflare 官网上的这篇文章[1]以及 The First Few Milliseconds of an HTTPS Connection[2] 在这里主要是讲讲在 TLS 中为什么需要 Client Random 以及 Server Random. 导言首先先从 https 如何防止 MITM(Man-In-The-Mi

Introduction在分布式系统中我们提到的 consistency 不同于 ACID 的 consistency (或者说是 correctness), 它描述了在 replicated database 中我们在某一时刻在不同的节点看到的数据状态应该是怎么样的。 在最为理想的情况下，如果系统提供的是强一致性的保证，针对某一个数据项的更新操作成功后，那么所有的用户都可以立刻读取到更新后的值。

ACID Atomicity: All-Or-Nothing. Transaction 涉及到的多个操作要么一同完成，要么什么都没有做，不能处于 half-finished 的状态。因为各种各样的 fault （比如crash、network connection interruption 以及 disk fail 等问题）可能会导致事务中的操作并没有全部完成，atomicity 为数据库的状态提