使用 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 多年的难题：如何知道一个对象已经被析构了。

前段时间趁着春节，分别基于 IOCP 和 epoll 实现了 demo 级别的 http server（在遵守 http 1.1 socket 复用基础上只提供了某个指定目录下文件的 GET），算是简单的过了一下 proactor 和 reactor 模型下的 TCP 并发服务。

功能做的很粗糙，并且没有封装类似 event-loop 的东西，连接管理也基本算是纸糊的，原因还是前面说过的，只是想过一下两种模型，并且，在不研究当前流行的 paradigm 的前提下，凭借自己的 first understanding / hunch 去实现；等对这块有一段时间的研究后，作为参照，来回对比以加深理解。

周末的时候客服同学反馈有个用户出现了崩溃，并且要来了崩溃 dmp 文件。

挂上 windbg 后发现崩溃原因是 CRT 的 invalid-parameter 异常，第一现场是输出 ffmpeg 的 avcodec 模块的日志。

省略中间若干分析过程，直击结论：FFmpeg 的 Windows 构建并不是用 MSVC 编译的，因此在类似 printf() 函数的 format specifier 使用上出现了偏差。