C++ 的 std::unique_ptr 有个神奇的特性：如果使用默认的 deleter（即使用 operator delete），或者 non-capturing lambda 作为 deleter，则有

1

sizeof(std::unique<T>) == sizeof(void*);

即整个对象的内存布局和 trivial pointer 一致，没有额外的开销。

这个特性的背后就是 compress-pair；这个设施能够在某个元素是一个 empty class 时避免为其分配内存。

注：这里假设你知道什么是 EBO，以及为什么会有 EBO。

这里自己动手实现一个 compressed pair：

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

template<typename Tx, typename Ty, bool = std::is_empty<Tx>::value>
struct CompressedPair : Tx {
    Ty second;

    template<typename T>
    explicit CompressedPair(T&& t)
        : Tx(),
          second(std::forward<T>(t))
    {}

    template<typename T, typename U>
    CompressedPair(T&& t, U&& u)
        : Tx(std::forward<T>(t)),
          second(std::forward<U>(u))
    {}

    Tx& get_first() noexcept
    {
        return *this;
    }

    const Tx& get_first() const noexcept
    {
        return *this;
    }
};

template<typename Tx, typename Ty>
struct CompressedPair<Tx, Ty, false> {
    Tx first;
    Ty second;

    template<typename T, typename U>
    CompressedPair(T&& t, U&& u)
        : first(std::forward<T>(t)),
          second(std::forward<U>(u))
    {}

    Tx& get_first() noexcept
    {
        return first;
    }

    const Tx& get_first() const noexcept
    {
        return first;
    }
};

因为 EBO 是实现的核心，而父类的构造顺序先于子类的任何成员，上面将 Tx 作为可被优化的成员。

过去两周抽了点时间给 KBase::CommandLine 做了一个变更，重新设计了 parameter 和 switch 的用户访问接口。

Concurrency

Roll Your Own Lightweight Mutex

核心是 Jeff Preshing 大牛的两篇文章

• Roll Your Own Lightweight Mutex

0x00

前段时间专门抽空做了一个小工具，也就是这里要讲的主题：anvil

一开始做 anvil 的动力很简单：某次尝试体验一下 Linux SignalFD 功能时想直接使用 ezio 的 EventLoop 作为基础事件循环，同时项目使用 cmake 管理。

为了省事，我直接从 ezio 的项目里抠出来 CMakeLists.txt 和几个自己写的 .cmake 文件，就地修改。

但事实证明哪怕这样，改动量也不小，原因大体是因为：cmake 里（非函数内定义的）变量作用域是全局的，通过 fetch-content 功能引入的依赖在 add_subdirectory() 后的模块里也能看到上一层定义的变量，因此为了防止一些控制型变量发生冲突，我都在前面加上了对应的模块前缀。

所以我面对的就是一大坨变量名的更换，以及少部分声明/属性的调整。

考虑到大部分的文件内容都是可以模板化的，而手动“实例化”不仅费事还很容易出错，所以我就很自然地萌生了写一个工具自动化这个过程的想法。

0x01

在经过一两天的短暂思考后，我大致确定了这个工具的定位和需要实现的基本目标，总结起来有三个核心点：

1. 辅助 cmake 而不是试图替代它或深度封装
2. 内建一个轻量型的依赖管理功能
3. 配置化的生成 & 构建流程

首先，第一点是重中之重。

Programming Languages

Destructors that throw

C++ 11之后的 destructor 默认是 noexcept，如果有 active exception 逃逸出 dtor 会直接触发 std::terminate()，即使外部有 catch handler。可以用 noexcept(false) 显式关闭。

因为 stack unwinding 是可以嵌套的，一个精心设计的场合下（见文中例子），可以做到多个 active exception 不在一个层次里，因此也不会触发 double-exception situation。

Who calls std::terminate?

an exception leaves out from main function

an exception leaves out from initial function of a thread

an exception leaves out from dtor (since c++ 11 with noexcept guarantee)

大部分人应该都知道 DNS 协议，以及它的用处。但是考虑过自己动手写 DNS message transmission 的应该不占多数。

我们不妨考虑如何自己实现一个简单的 DNS client，完成基本的 domain name query and response parsing。

因为 DNS 协议通常使用 UDP 作为其传输层协议，而且数据包是二进制包，所以实现一个这样简单的 demo 考虑用 golang 可能会省事儿不少。

DNS Message Format

大体上 DNS 不是一个复杂的协议（虽然各类坑实在不少），所有的消息，不管是 query 还是 reply，都共享一个消息格式：

1
2
3
4
5
6
7
8
9
10
11

+---------------------+
|        Header       |
+---------------------+
|       Question      | the question for the name server
+---------------------+
|        Answer       | Resource Records (RRs) answering the question
+---------------------+
|      Authority      | RRs pointing toward an authority
+---------------------+
|      Additional     | RRs holding additional information
+---------------------+

• Header：消息头，包含一些参数、标志位
• Question：包含 query 的信息，例如需要查询的 domain
• Answer：reply 的信息
• Authority：如果有信息，则表明应答的服务器是 ultimate authority server。别忘了 DNS 服务器是树形结构，通常终端用户查询的 DNS 服务器都是 local DNS server。
• Additional：服务器传回的一些额外数据，非用户显式需要的

对于一个 query message，Answer section 是空的；而对于一个 reply message，Question 保存着对应 query 的数据。

一般而言，终端设备收到的 reply 消息里，Authority 和 Additional 是空的。所以下面会跳过这两个 section 的描述。