为什么是 basic_fstream<unsigned char> 比 basic_fstream 慢一个数量级<char>在 Windows 上？

Question

在一个程序中，我正在以下列方式处理一些用于字节的别名：

#include <fstream>
#include <vector>
using Byte = unsigned char;

void write(const Byte* buffer, size_t size) {
    std::basic_fstream<Byte> file("1gb_file", std::ios::in | std::ios::out);
    file.write(buffer, size);
    file.flush(); // To ensure the data is being written, to eliminate caching claims
}

int main(){
    auto GB = 1024u * 1024u * 1024u;
    std::vector<Byte> zeros(GB, 0);
    write(zeros.data(), zeros.size());
    return 0;
}

这个函数在Byte == unsigned char上执行的时间：52.0245s 在我全新的 SSD 上，MSVC-x64 在发布模式下。

另一方面，如果我们将定义更改为Byte == char : 1.46725s。 而已。

为什么会有这种差异，是否有使用标准库避免此类陷阱的一般良好做法？

注意（由于错误而编辑）：正如@SergeyA 指出的那样，在 Linux 上，当给出 unsigned char（在 gcc 和 clang 上）时，代码实际上无法运行。 Windows 上的 GCC 版本也无法运行，这与我之前写的相反。

Answer 1

我要硬着头皮在这里猜测这与语言环境有关。 基于我所拥有的非常有限的信息，它看起来像是在 MSVC 无符号字符流中执行区域设置转换，而普通字符流则不会，而只是进行批量 IO。 （请参阅http://en.cppreference.com/w/cpp/io/basic_ostream/write 上的注释）。

有趣的是，相同的代码片段在我使用 g++ 5.4 的 Linux 安装上根​​本不起作用（我知道，相当旧）。 由于流类中的某些内部成员为 nullptr（感兴趣的人是 _M_codecvt）并且设置了流的badbit因此写入失败。