【发布时间】:2018-04-03 18:43:49
【问题描述】:
我在从 boost asio 的流中读取时遇到问题。 async_read_until 的第一次调用给了我 460 个字节的传输(我用 wireshark 检查过)。之后,我使用使用 streambuf 指针初始化的 istream 来使用带有 istreambuf_iterator 的 std::copy_n。这工作正常,std::copy_n 的目标将请求保持到分隔符序列。
奇怪的事情发生在下一次调用 async_read_until 之后。似乎没有从 streambuf 中读取最后一个字符,因此下一个处理程序调用给了我比请求的实际大小多一个字节。
将 istream 与 asio 的 streambuf 一起使用有什么限制吗?
【问题讨论】:
-
您是否正确使用了
commit()和consume()函数?你能展示我可以复制粘贴到我的 IDE 中检查的最少、完整的代码吗? -
我不使用任何提交或消费功能。我只是将流缓冲区用于 std::istream 并使用 istreambuf_iterators。经过一番试验,我发现了问题: std::copy_n 正在用迭代器做奇怪的事情。使用 while 循环并调用 ++ 运算符可以正常工作。不使用 commit 或 consume 并仅从 streambuf 制作 ostream 或 istream 有什么问题吗?
-
如果您在 istream 或 ostream 中使用流缓冲区,则提交/使用机制已为您完成。
-
好的,现在一切都很好。我最终没有使用 std::copy_n 因为它似乎省略了消耗最后一个字符,所以它仍然保留在缓冲区中。这会干扰下一次读取操作。不知道这是否是 std::copy_n 的意图。
-
@Gustavo copy_n 打算复制
n个字符。由于源是一个输入迭代器,它应该被期望增加(最多)n次。 en.cppreference.com/w/cpp/algorithm/copy_n
标签: c++ boost boost-asio