使用 basic_ostream 重载 operator<<

Question

为什么带有用户定义类C 的流操作的典型标头通常是这样的：

std::ostream& operator<<(std::ostream& os, const C& c);
std::istream& operator>>(std::istream& is, C&);

不是这样的：

template <class CharT, class Traits> 
std::basic_ostream<CharT, Traits>& operator<<(
        std::basic_ostream<CharT, Traits>& os
        const C& c);

template <class CharT, class Traits> 
std::basic_istream<CharT, Traits>& operator>>(
        std::basic_istream<CharT, Traits>& is
        C& c);

我的问题是为什么流运算符的通常重载是用std::ostream 完成的，这是char 的std::basic_ostream 的typedef，为什么不直接用std::basic_ostream 完成？

例如：

class C
{
    ...
};

std::ostream& operator<<(std::ostream& os, const C& c)
{
    ...
}

int main()
{
    C c;
    std::wofstream myFile("myFile.txt");
    myFile << c; //Impossible
}

这里写的operator<< 限制我们只能使用专用于char 的流对象（std::ostream，std::ostringstream，...）。 所以如果使用std::ostream 比std::basic_ostream 更受限制， 为什么在谈论流运算符重载时从未提及std::basic_ostream？

Answer 1

实际上，使用了两种不同的字符类型：

1. Windows 使用 wchar_t 是因为 Unicode 人很久以前做出的承诺（Unicode 将只使用 16 位，并且每个字符仅由一个单元组成），并且自那以后就被打破了。李>
2. 其他人都使用char，它现在主要被认为是 UTF-8 编码中的一个字节（显然，不是普遍的）。

回想起来，引入wchar_t（甚至更多的是char16_t和char32_t）是不明智的，如果只使用char，世界会变得更好。因此，那些不受 Windows 困扰的人并不关心 I/O 操作的wchar_t 版本，并且 Windows 通常似乎在 IOStreams 上进行攻击（众所周知，MSVC++ 实现很慢并且意图为零做任何事情）。

另一个原因是，编写模板化 I/O 操作符会增加已经很复杂的系统的复杂性。似乎很少有人了解 IOStreams，而其中对支持多种字符类型感兴趣的人更少。

模板化 I/O 操作符的感知复杂性的一个方面是假设实现需要进入标头，这当然不正确，因为 IOStreams 基本上只有两种字符类型被实例化（@ 987654329@ 和 wchar_t)：虽然 IOStreams 可以用其他字符类型实例化，但我很确定几乎没有人真正这样做。尽管我知道这需要什么，但我可能仍需要至少一天的时间来定义所有必要的方面。因此，模板定义可以在合适的翻译单元中定义并在那里实例化。或者，与其将运算符定义为模板，不如将它们完全专门化。

独立于模板化操作符的定义方式，一般来说工作量更大。如果天真地完成（即直接使用例如std::ctype<cT>），结果会很慢，如果做得正确（即缓存来自std::ctype<cT>的结果），它会非常复杂。

综合考虑：何必呢？

如果我必须写入std::wostream 或从std::wistream 读取，我实际上会创建一个过滤流缓冲区，它只使用合适的std::codecvt<...> facet（甚至只使用@987654336）转换写入/读取的字符@ 的 widen() 或 narrow())。它不会处理字符串的正确国际化，但std::locale 设施无论如何都不能真正达到正确的国际化（为此您需要ICU 之类的东西）。