Windows 在进程间通信 pipe 中发送前两个字节字符时，是否会自动添加一个 EOL 作为签名？

Question

我有一个关于通过 Windows 管道发送命令和数据的一般性问题。 在Unix操作系统上好像没有出现这个问题。

这个问题并不特定于我的应用程序，但出于说明目的，我将使用gnuplot-iostream和matplotplusplus C++ 库通过两个示例来解释我的问题。

Gnuplot-iostream

在我的应用程序中，我通过gnuplot-iostream与gnuplot交互，它是 C++ IO stream API。

简而言之，gnuplot-iostream API 作为一个简单的 header 文件分发，其中链接到 boost-iostream 库以将命令和数据发送到 gnuplot 应用程序。 为此，API 在用户的 C++ 程序和 gnuplot 之间打开一个 pipe，并且通过一个非常薄的抽象层，用户能够通过 pipe 发送命令和数据。

将数据发送到 gnuplot 时，我注意到第一个数据点没有正确绘制。 经过非常仔细的调查，我发现通过 pipe 发送的数据的前两个字符被忽略了。

考虑以下代码片段。

#include <vector>
#include "gnuplot-iostream.h"

std::vector<double> x = {-1.45809};
std::vector<double> y = {1.34003};
std::vector<double> z = {3.92172};

Gnuplot gp(stdout);
gp << "set view 90, 0\n";
gp << "set xlabel 'x'\n";
gp << "set ylabel 'y'\n";
gp << "set zlabel 'z'\n";
gp << "splot '-' with points\n";
gp.send1d(boost::make_tuple(x, y, z));

在绘制上面的图时，我注意到 gnuplot 收到 x = 0.45809，这意味着“-1”已被截断。 下面是我屏幕上的图像证明。

我认为这种截断是由于 Windows 在前两个字符的末尾添加了一个 EOL。 下一个例子有望澄清我的主张。 请注意，此错误尚未正式报告，但 gnuplot-iostream 的作者报告了 Windows 用户的 iostream 的几个问题，但尚未修复。

地图加加

Matplotplusplus是另一个使用 C++ 的 API 到 plot 图形，其界面与 Python 的 matplotlib 非常相似。这个 API 不使用 Python 解释器，与后端 gnuplot 通信作为

细节我就不多说了，但是仔细查了源码后，碰巧在运行一个简单的“hello world”绘图程序时，并没有出错，但是控制台输出了如下的警告信息。

gnuplot> se
           ^
         line 0: unrecognized option - see 'help set'.

gnuplot> t terminal wxt title "Figure 1" size 560,420 enhanced font "Sans,10"
         ^
         line 0: invalid command

对我来说，很明显 Windows 在前两个字符的末尾添加了一个不需要的“\n”。 发送的所需命令应为： set terminal wxt title "Figure 1" size 560,420 enhanced font "Sans,10" ，但“set”的“se”已被截断。 所以 Windows 已经发送： se\nt terminal wxt title "Figure 1" size 560,420 enhanced font "Sans,10" instead. 顺便说一句，我不是唯一报告此错误的用户。

我的问题如下。 由于 Windows，是否有可能绕过这个烦人的问题？ 为什么这么无用的两字节签名要通过pipe发送呢？ 解决这个问题的一个简单技巧是在字符串中添加两个空格并在发送实际数据之前发送一个虚拟签名命令，但这不是一个干净的解决方案。

你知道我应该朝哪个方向寻找来解决这个问题吗？ 是boost库问题还是Windows问题？ 使用 Unix 操作系统似乎没有什么大惊小怪的，因为 pipe 结构很好地集成到操作系统中。 在 Windows 的情况下，操作系统 pipe 结构完全不同，这可能导致不可靠的通信问题。

Answer 1

需要刷新 output stream 缓冲区。