仿muduo实现高并发服务器——读写缓冲区Buffer.hpp

摘要

Buffer.hpp 是 header-only 实现：#include 即用，无需链接 .cpp/.a/.so。内部为 std::vector 加 _redidx/_wrtidx 两个下标，提供写入、读取、容量查询、按 '\n' 取行。价值是把容量、size 与下标解耦：地址由 Begin()+下标算出，End() 取容量末端，避开读下标偏移后 size 难定。

代码仓库：https://gitee.com/btshadow/Ubuntu_learning/blob/master/October/10-16/muduo/src/server.hpp

注释

3.1 回顾

override 是检测重写，不是重载。

3.2 新知识

const_cast 只去指针/引用层面的 const，不改对象存储属性：原对象非 const 时去掉后修改合法；对象本身为 const 时改属 UB，可能崩溃、被优化或暂时正常。Write() 内 const_cast 按此理解。

调试要善于、适当使用 AI：gdb 里看 void* 的 data 用 p (char*)data，输出对比：

text 复制代码

$2 = 0x7fffffffdd90 "hello"
$1 = 0x7fffffffdd80 "\220\335\377\377\377\177"   // \220=0x90 \335=0xDD \377=0xFF \177=0x7F

字节呈小端序指针形态，说明它是 string 内部结构的指针而非字符内容，故 string 要单独重载。

3.3 注意

重点是 vector 管理与 idx 的分离性；课件内 size 不明确，单一成员变量下难解，erase 又会留左侧「空洞」，故不 erase、只靠 _redidx；std::copy 不支持重叠拷贝，左移改用 memmove。

3.4 反思

按老师所讲做必要的重构与补充；优化前先想好思路、问 AI 能否实现（erase 根本无法实现）。End() 处另记：良好的编程习惯加画图分析很重要。反思第 3 条原文为空，【待我补充】。

正文

下文函数均在 Buffer.hpp 内。成员只有 _buf、_redidx、_wrtidx：写走 Write→EnsureEnoughCapacity，右侧不足先 memmove 左移、再 reserve 扩容、重算两下标；读走 Read/ReadLen，推进 _redidx 且不 erase；另有 ReadOnly/WriteOnly（先读写再回退下标）、Write(string)、FindCRLF/GetLine（按 '\n' 切行）。Begin() 取 &(*_buf.begin())，End() 取 Begin()+capacity() 而非 _buf.end()（注释作「神之一手」）。

4.1 开发中遇到的问题

bug1：误把 string* 传进 void* data；gdb 显示它指向 string 内部结构而非字符内容（见 3.2），故 string 要单独重载，动代码前先确认指针指向。

bug2：resize 会销毁（重置）强行用 _buf 下标访问纳入的内容，该行为未定义，故 Write() 里 resize 那行被注释。

bug3：ReadLen 第一个循环漏了 len 变量，会把可读区整段读完：

cpp 复制代码

// 原：漏 len
for (; _redidx < _wrtidx; _redidx++)
// 现：以 _redidx + len 为界
for (uint64_t i = _redidx; i < _redidx + len; i++)

总结

设计核心是双下标加 Begin()+偏移寻址、End() 表达容量；bug1/2/3 分别对应类型误传、越界下标写入、循环边界缺失。仓库链接指向 server.hpp，文件名为 Buffer.hpp，对应关系【待我补充】。

常见问题

End() 为何不取 _buf.end()？下标体系以容量为界，_buf.end() 只是有效元素末端。
ReadLen 读完为何不 erase？会破坏下标语义并留左侧空洞，_redidx 已够描述。
左移为何用 memmove？源目标重叠，std::copy 不支持重叠拷贝。
Write 为何单独重载 string？见 bug1，void* 分支收到的是 string 结构指针。