Life

• 这周各地都在冒疫情的病例，不知道是好消息还是坏消息。不过看趋势大概率清明应该没法回温州了
• 抽个时间补了 The Thing 正传；正传的节奏和BGM都肉眼可见的比后来的前传要好

Life

• 这周沉迷 The Witcher S02，一周时间就把第二季刷完了。
  作为没玩过游戏的受众，人物选角没有让我有太强的违和感，没办法，Henry Cavill 的 Geralt 太香了，一人撑起全剧。当然，Yennefer 要是 Evan Green 来演我觉得更赞。 期待后续剧集

Life

• 刷完了 The Expanse S05；这一季主要仍是在做剧情铺垫和完善角色形象，但是这已经是倒数第二季了，这个时候才开始要丰满主要反派 Marco Inaros 的形象未免也太晚了吧。何况还要顺带加上 Philip…这就导致这一季又重复了一遍之前的旧模式，缺乏点新意。
  另外这一季 Alex 的演员因为性骚扰丑闻被剧本杀了，Clarissa 加入队伍，不得不感慨一下。
  同时 Mrs.Avasarala 重新当选为联合国秘书长；以及 White Collar 里的 Peter 叔 Tim DeKay 打了个酱油，出演反叛的 MCRN 军官，结果最后一集在穿越 Ring 的时候直接被湮灭了…

节后第二周，生活和工作节奏都慢慢恢复到了之前的状态。

Life

1. 一口气刷了好几集 The Expanse S05，感觉 S05 前半部分又在攒局积攒冲突。但是一个不好的地方是核心冲突又回到了人上，protomolecule 还是“飘在外面”；期待后续有更高的格局

Blog 从上次更新到现在至少荒几个月。一直没更新主要是太懒了并且没有想到有什么需要特别写的。

春节休假期间偶尔反思了一下觉得还是需要日常回顾自省一下，就算没有什么新的体会或者收获，当 journal 留着万一哪天得了阿兹海默症没准还能起到正向作用 🤪。

Life

因为节前几天杭州出现了不大不小的疫情，出现扩散后老婆医院不允许医护回家所以又一起在杭州过了一次年。所以节后就没有请年，开始恢复工作节奏。

之前在 用 unique_ptr 管理 Windows HANDLE 中介绍了如何基于 std::unique_ptr 快速实现对 Windows HANDLE 的 RAII 化。

但是如果我们也要对 fd 或者 Windows 上的 SOCKET 做类似的处理，重复实现 xx_handle 和 xx_handle_deleter 就显得过于琐碎。

实际上我们可以利用模板参数注入，将共同点抽象出来，不同点实现成各自的 type traits，然后利用模板进行注入。

这样一来，我们只需要简单实现每个 handle type 对应的基础属性，就可以直接复用核心实现。

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

template<typename Traits>
class handle_ptr {
public:
    using handle_type = typename Traits::handle_type;

    handle_ptr() noexcept = default;

    // implicit
    handle_ptr(std::nullptr_t) noexcept {}

    // implicit
    handle_ptr(handle_type handle) noexcept
        : handle_(handle) {}

    ~handle_ptr() = default;

    explicit operator bool() const noexcept {
        return Traits::is_valid(handle_);
    }

    // implicit
    operator handle_type() const noexcept {
        return handle_;
    }

    friend bool operator==(handle_ptr lhs, handle_ptr rhs) noexcept {
        return lhs.handle_ == rhs.handle_;
    }

    friend bool operator!=(handle_ptr lhs, handle_ptr rhs) noexcept {
        return !(lhs == rhs);
    }

private:
    handle_type handle_{Traits::null_handle};
};

template<typename Traits>
struct handle_ptr_deleter {
    using pointer = handle_ptr<Traits>;

    void operator()(pointer ptr) {
        Traits::close(ptr);
    }
};

PS：不同于文章中的例子，基底类起名 handle_ptr 更为确切；因为在 unique_ptr 的内部会用来定义 pointer；而几乎 unique_ptr 的语义行为都是围绕 pointer 来完成的。

有了上面这个基底之后，针对 fd-wrapper，我们只需要

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

struct fd_traits {
    using handle_type = int;

    static bool is_valid(handle_type handle) noexcept {
        return handle != null_handle;
    }

    static void close(handle_type handle) noexcept {
        ::close(handle);
    }

    static constexpr handle_type null_handle{-1};
};

using fd_deleter = handle_ptr_deleter<fd_traits>;
using unique_fd = std::unique_ptr<fd_traits::handle_type, fd_deleter>;

inline unique_fd wrap_unique_fd(int raw_fd) {
    return unique_fd(raw_fd);
}

这样一来，实现一个新的 unique handle wrapper，我们只需要确定四个东西：

1. handle type 的实际类型
2. null handle 的值，用来确定 default/zero initialized 之后 handle 状态
3. 实现 is_valid()
4. 实现 close()

剩下的就是常规的类型实例化。

C++ 11 引入了没有掀起什么波澜的 std::error_code 和几乎没收到什么关注的 std::system_error。

偶然发现后者可以用来做针对 system calls 的异常汇报处理。

0x0 A Traditional Approach

Win32 API 调用失败后具体的错误码可以通过 ::GetLastError() 获取；Linux 上 syscall 的错误码则用更 C-ish 的 errno 获取。

如果希望通过异常来汇报这些系统调用失败，那么通常会从 std::runtime_error 继承出一个 exception class，额外包含系统调用的错误码。

例如：

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

class win_last_error : public std::runtime_error {
public:
    using error_code_type = unsigned long;

    explicit win_last_error(const char* msg)
        : runtime_error(msg),
          error_code_(::GetLastError()) {}

    [[nodiscard]] error_code_type error_code() const noexcept {
        return error_code_;
    }

private:
    error_code_type error_code_;
};

上面的代码稍加处理后可以同时支持 GetLastError() 和 errno

0x1 Using std::system_error

std::system_error 恰好也是一个和 system facilities 有关的异常类，汇报系统相关的错误。

除了传统的 what() 之外它还提供一个 code() 函数返回对应的 error_code

而 std::error_code 可以通过指定不同的 category 来指示其包含的错误码语义。

所以实际上我们可以这么用：

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

inline pipe make_pipe() {
#if defined(OS_WIN)
    ...
    if (::CreatePipe(&fds[0], &fds[1], &sa, 0) == 0) {
        throw std::system_error(std::error_code(::GetLastError(), std::system_category()),
                                "CreatePipe() failure");
    }
    ...
#else
    ...
    if (::pipe(fds) != 0) {
        throw std::system_error(std::error_code(errno, std::system_category()),
                                "pipe() failure");
    }
    ...
#endif
}

注意这里使用的 system_category()，它代表 error code 是 reported by the system.

有些地方可能会说这里要使用 std::generic_category；但是通过试验发现使用 std::generic_category 的 Windows last-error 和 ec.message() 是对不上的；而 std::system_category() 则是正确的。

猜测 generic category 可能针对的是 CRT 的错误码

0x2 Q&A

Q: error_code 是啥？
A: 这玩意儿实际上是 ASIO 的作者针对 async-handler 的错误处理设计的；boost 中 ASIO 和 filesystem 都大量支持了它。

但是这玩意儿的设计门槛有点高，以至于不看完几篇文章压根没法理解这东西的设计意图；导致除了 ASIO 和 filesystem 及他们相关的衍生 lib 之外都没啥人去用它。

而 filesystem C++ 17 才进入标准；而 ASIO/network TS 几天前也差不多宣告死亡了…

Q: 为啥要用异常？
A: Why not？我不排斥使用异常，而且我觉得我写的东西还没关键到需要考虑目前异常实现带来的性能问题。

并且我觉得 exception 在充满大量业务逻辑的应用层是非常优秀的错误处理机制。

即使提供了支持 chaining operations 的 sum type（例如这个 expected），在业务层基本也需要人肉实现 failure cascading 层层上抛。