最近互联网行业一片哀叹，这是受到三年影响的后遗症，许多的公司也未能挺过寒冬，一些外资也开始撤出市场，因此许多的IT从业人员加入失业的行列，而且由于公司较少导致许多人求职进度缓慢，很不幸本人也是其中之一。自从参加工作以来，一直都是忙忙碌碌，开始总认为工作只是为了更好的生活，但是一旦工作停下来后自己就觉得失去了一点什么，所以很少有像最近这两个月左右空闲的时光。人一旦空闲下来就未免有些空虚，空虚的原因大部分还是因为对未来的焦躁不安，比如要担心口袋余粮问题、担心兢兢业业的别人会投以不屑的目光。于是在这期间我也尝试应聘一些岗位，许多面试官问到plain framework是如何实现的时候，说实话一时间我没法准确的把他们想知道的内容表述清楚，一方面是自己的口才欠缺，一方面确实是因为时隔太久对许多的东西产生了一定的遗忘。大家不要奇怪为何自己会忘了自己写的东西，拿一件事来说就是我相信大多数人在工作之后对于自己曾经思虑再三觉得十分念念不忘的优美作文或者做题解法都说不出个所以然。人的记忆力是有限的，不然也就不会有那句好记性不如烂笔头的名言了。重构plain的计划实际上是从2019年C++准备发布C++20标准的时候产生的，其module模块概念的引入让我对于库开发产生了一种十分美好的期盼。特别是去年年初我就一直在关注C++23，因此在去年就决定在今年内准备完成对plain的重构，其版本号直接提升到了plain2.0，其原因是相比现在的plain1.1rc产生了比较多的变化。我想说的是重构这个框架的目的之一是重拾自己的记忆，完成既定目标的一部分，同时也是增强自己在modern C++方面的技术，希望在这里与朋友们一起学习和探讨设计中遇到的一些问题。同时也顺便提一句，大环境虽然是不好但是心中还是应当存有希望，寒冬过后一定会有春天，绝境之地也自然会有生机，盲目自怨自艾不如放松心情转换思维提升自己（当然这里不是说卷）。我相信未来总是美好的，祝愿那些失业或者正要失业的朋友们有个好的工作和生活，也祝福正在工作或者无需工作的活得快乐。同时也希望这系列文章（可能会写几篇），给大家能够带来一定的收获。顺道说一句，这一些列文章不是C++学习的基础，可能需要大家对该语言有一定程度的了解，该系列文章主要分享的是我在开发和设计中的一些心得体会，如果有不正确的地方希望大家在评论区留言，或者加入群联系我。我以前没有详细地写过这方面的文章，主要还是因为太懒，而现在写这些是因为人到了一定岁数是想要总结什么的时候了，再说如果中年危机得不到缓解，互联网或许不再是我的栖身之处，也希望在这里留下一些有用的知识能够让大家对网络编程有一定的理解。（这篇文章几乎花了一天时间，看来是因为自己反应力衰退了，如果大家认为有所帮助希望可以关注一下，后续我将继续分享）
原因
plain1.1rc的不足
１、命名空间问题
如果看过或者接触过plain的朋友，不难发现命名空间都是以pf_*开头。说起这个的时候，还是要从plain的前身plainserver（https://github.com/viticm/plainserver）说起。我看了看时间，emm...，时间大概是九年前，那个时候我还深处在南方的沿海城市。从名字上来说，让人很容易联想到服务器。这个项目有着非常强的针对性，是实现了一个服务器的常用模型，一个多进程多线程模式下的游戏服务器的实现。这套模型是许多现今仍旧有许多老的厂商（搜狐、金山等）可能仍在应用的模式。其应用的原因大致是这些公司成立时间早，在这方面应用该模式已经得心应手（成熟的相对是可靠的，企业不愿意冒风险去尝试，毕竟尝试是需要代价的）。有兴趣的朋友们不妨可以看一下其中的实现，我在以前的文章里提到过该构架并且用图画简单的画出了其模型。
大家不妨看看plainserver的common目录，这个目录下的结构，再来对比下plain下的那些目录，是不是感觉到有很多相似。没有错，plain就是在common上面衍生出来的，一个更精细、抽象和共用的库，本来common就是作为客户端和服务器的公用库而存在。然后重点问题来了，打开文件看看比如common/src/common/base/log.cc这个文件，看看其命名空间，不难发现namespace ps_common_base {，没有错这就是之前的命名规则，这是我看了google C++编码规范之后，自己想的一个命名规则，不难看出这里的规则是ps（项目名称）_common（父目录）_base（子目录）。
从上面的命名空间的规则，不难发现plain现在的命名空间实际上是在此基础上做了一点略微调整。自从接触命名空间后，我就尽量想要让函数或者对象被包裹起来，这样是为了减少跨模块之间的冲突。但是如果以纯粹用命名空间和目录结构来划分的话，那么目录的层次结构必然会嵌套很深。于是在plain的时候规定目录的嵌套最好少于三个层次，这样也约束了命名空间的嵌套。这样就形成了pf_basic、pf_sys等一些列的命名空间，同时也有二级嵌套pf_sys::thread这种。忘了提一点pf其实是plain framework的缩写，说实话这样命名本来没有任何问题。可是在使用中会发现一些命名空间和方法产生了重名，比如文件（file）模块，这里面封装了一些跨平台的文件操作接口，如下：
namespace pf_file { namespace api { PF_API int32_t openex(const char *filename, int32_t flag); PF_API int32_t openmode_ex(const char *filename, int32_t flag, int32_t mode); PF_API void closeex(int32_t fd); PF_API uint32_t readex(int32_t fd, void *buffer, uint32_t length); PF_API uint32_t writeex(int32_t fd, const void *buffer, uint32_t length); PF_API int32_t fcntlex(int32_t fd, int32_t cmd); PF_API int32_t fcntlarg_ex(int32_t fd, int32_t cmd, int32_t arg); PF_API bool get_nonblocking_ex(int32_t socketid); PF_API void set_nonblocking_ex(int32_t socketid, bool on); PF_API void ioctlex(int32_t fd, int32_t request, void *argp); PF_API uint32_t availableex(int32_t fd); PF_API int32_t dupex(int32_t fd); PF_API int64_t lseekex(int32_t fd, uint64_t offset, int32_t whence); PF_API int64_t tellex(int32_t fd); PF_API bool truncate(const char *filename); PF_A