前几天在写一个 ThreadPool 的轮子的时候，碰到一个问题：无论我用什么办法，都不能将 std::packaged_task 传递到 std::function 中，编译器始终提示访问了 std::packaged_task 被删除的拷贝构造函数。

曾经为了能在 PostTask() 里使用 lambda，实现了一个自动将 non-capturing lambda decay 到对应函数指针，在利用 base::Bind() 的方案[1]。

使用 vcpkg 编译 libx264 有一个很重要的原因：可以获得 PDB，而且构建流程被大大精简了。

但是这里有一个坑：vcpkg 上的 libx264 模块编译默认是开启了 --disable-asm，意味着构建之后的二进制不会使用 SIMD 指令集，所以性能上会有很大的问题。

Sorting, caching and concurrency

通过引入基于时间的 sliding window 来标记并剔除（大概率）由错误产生的数据；并且可以利用 SW 来 schedule 数据什么时候从内存持久化到磁盘。

序言请移步此处

MSVC STL 的分析版本请移步此处

注：因为这不是第一篇分析，所以会直入主题，跳过文学写作常用的累赘的过渡。

版本选择与源码位置

目前的工作机是 Linux Mint 18，对应的是 Ubuntu 16.04 LTS。

这个版本的系统上源包默认提供的是 GCC 5.4 和 clang 3.8，跟随的 libstdc++ 的大版本是 6。

考虑到 Linux 上 clang 也是默认使用 libstdc++，且 GCC 6/7/8 使用的 libstdc++ 的大版本都是 6，因此直接选用目录 /usr/include/c++/5 下的源码作为研究对象。

序言请移步此处

因为这是系列第一篇，所以会带一些功能的 demo，以方便叙述。

How shared_ptr(new T()) differs from make_shared()

首先考虑 shared_ptr 对象的创建，对于给定类型 T，假设通过

1

auto ptr = std::make_shared<T>(...);

创建一个实例。

看一下函数代码：

1
2
3
4
5
6
7
8
9
10
11

template<class _Ty,
         class... _Types>
_NODISCARD inline shared_ptr<_Ty> make_shared(_Types&&... _Args)
{
    // make a shared_ptr
    const auto _Rx = new _Ref_count_obj<_Ty>(_STD forward<_Types>(_Args)...);

    shared_ptr<_Ty> _Ret;
    _Ret._Set_ptr_rep_and_enable_shared(_Rx->_Getptr(), _Rx);
    return (_Ret);
}

这里首先在 heap 上创建了一个 _Ref_count_obj<_Ty> 对象，通过 std::forward() 将 make_shared() 的参数转发作为构造函数；接着通过 default contructor 创建了一个 shared_ptr<_Ty>，并调用 _Set_ptr_rep_and_enable_shared() 设置相关数据。

因为创建 _Ty 实例需要的参数 _Args 被转发到了 _Ref_count_obj 的构造函数中，且 shared_ptr 的 default constructor 实质上是一个 _constexpr function_，因此猜测 shared_ptr 自身并不负责创建其管理的 object instance，而是将这部分操作“委托”给 _Ref_count_obj。

单看标准库而言，shared_ptr/weak_ptr（后文除特指外，不再同时带上 weak_ptr） 一开始作为 TR1 的一员引入，低调行事多年后自 C++ 11 开始成为标准库正式成员。

在历史意义上，引入 shared_ptr 不光规范化了 resource ownership 作为 abstraction conception，同时解决了困扰广大 C++ programmers 多年的难题：如何知道一个对象已经被析构了。