近段有相当一部分时间在熟悉和练习 ASIO。
练习过程中发现 ASIO 中如何使用&管理 buffer 是新手大概率会遇到的问题。
结合最近几个 practice demo，稍微简单总结了一下使用经验：
0x00
const_buffer 和 mutable_buffer 是两个 fundamental buffer classes。二者的区别在语义上表达的很明显了。
实现上二者提供的接口非常一致，除了一个面向 const void*，另一个面向 void*。这点可以从 ctor 和 data() 中看出。
另外，为了和 C++ 现有的 const cast semantics 保持一致，一个 mutable_buffer 对象可以 implicitly converted to const_buffer。
首先承认这个标题乍看之下很像 troll，但真的不是 troll；“避免使用”总的来说更接近 whenever possible 的意思。
另外，这篇 post 面向的主要是偏底层的、直接使用 system calls 或其 runtime wrapper（glibc）的开发者，最典型的比如 C/C++ 开发者。
其他语言的开发者通常因为要么 runtime “屏蔽”了这部分内容（如 Java）；要么 runtime 自身对这部分做了较大的抽象/改造（如 Golang），因此很难对此 post 提到的各种观点/做法产生共鸣。
FYI：自从工作后中文写作能力一直在退化，因此这篇文章如果存在语句不通顺或者用词不当的地方，烦请见谅。
signal 源自 Unix，后来成为 POSIX 标准的一部分，现在则被几乎所有的 *nix 系统支持。
signal 本质上是一种通讯机制，用于系统在某个事件（event）发生时通知某个进程（或线程）。
其实是 Jeff Preshing 的 Acquire and Release Fences Don’t Work the Way You’d Expect 这篇文章的笔记。
拿 learn-asio 这个项目练手时发现一个问题：learn-asio 依赖了 KBase，这两个项目都是我用 anvil 进行托管的，所以两个项目的 cmake 目录里各自有一份 compiler_*.cmake。
因为 compiler_*.cmake 提供的函数 apply_common_compiler_property_to_target() 默认使用了非常严格的属性，导致构建 asio 练手工程出现很多 warning 和静态分析的错误，所以为了省事我把 learn-asio 的这个函数做了宽松化处理。
考虑到 ASIO 的相当一部分组件（subset）已经进入了 C++ 20 Networking TS，未来再经过一些小调整之后成为标准库的一员基本板上钉钉。
那么提前熟悉一下 ASIO 也不是什么坏事，毕竟没准等到 C++ 23 的时候，coroutine, networking, executor 啥的都已经很完备了，谁都可以用 C++ 实现一些性能不差的 server-end 代码了（比如 RPC 框架？）。
不过和使用 Boost 类似，使用 ASIO 作为依赖库也不是一件容易的事情；毕竟自 modern C++ 元年至今都8年了，CMake 还在成为 de facto building system 的道路上挣扎，广泛接受的包管理依然不见踪影…
陈年老账就不再扯了，得益于 CMake 3.2 开始提倡的 taget-based properties 和 CMake 3.11 开始提供的 FetchContent module，我花了一些时间实现了一个基于 FetchContent 的 asio-cmake wrapper。