在我看来，C++ 标准中存在不一致之处，特别是在 C++17 草案 (N4659) 的 §30.7.5.2.4 中，关于何时在输出流上的格式化输出操作中加宽字符 (operator<<()）。完全相同的不一致似乎也反映在en.cppreference.com http://en.cppreference.com/w/cpp/io/basic_ostream/operator_ltlt2.
首先，假设有以下声明：
std::ostream out;
std::wostream wout;
char ch;
wchar_t wch;
const char* str;
const wchar_t* wstr;
然后指出
-
out << ch does not执行字符加宽，
-
out << str执行字符加宽，
-
wout << ch执行字符加宽，
-
wout << str执行字符加宽，
-
wout << wch does not执行字符加宽，
-
wout << wstr执行字符加宽。
第一个也是最明显的不一致是（6）不可能为真，因为没有widen()函数取一个wchar_t论点，只有一个需要char争论。
第二个（看似）不一致是在（1）和（2）之间。我觉得很奇怪out << "x"应该加宽'x', while out << 'x'不应该。
我是否误解了标准文本，或者那里有什么问题？如果后者是真的，你知道预期的行为是什么吗？
编辑：显然，这种不一致（如果我是对的）至少从 C++03 (§27.6.2.5.4) 开始就已经存在于标准中。通过中间标准，文本略有变化，但正如我上面所解释的，不一致之处仍然存在。
看起来这个标准并不完全正确。大多数问题源于各自操作的批量规格。不是单独处理每个重载，而是一起描述类似的重载，从而导致误导性的规范。
不过，我怀疑任何实施者都难以理解其意图。本质上当一个char被插入到一个非char流字符需要widen()ed 获取流的字符类型的字符。这种加宽旨在将源字符集中的一个字符映射到流的宽字符集中的一个字符。
请注意，IOStreams 规范假定流中的字符的原始概念是单独的实体。自从创建规范（针对 C++1998 版本）以来，文本并没有真正更新，但随着 Unicode 的广泛使用，流中的“字符”实际上是编码的字节。虽然流在这个修改后的环境中大部分功能正常，但一些有助于处理 Unicode 字符的灵活性并未得到真正正确的支持。缺少将一个字符“扩展”为一系列 UTF8 字节的东西可能就是其中之一。
如果您认为流部分中的不一致/不正确之处需要解决，请提交缺陷报告。有关提交缺陷报告的说明位于http://isocpp.org https://isocpp.org/std/submit-issue。当您确实提出问题时，请考虑提供建议的措辞来纠正问题。由于并不缺乏明确的实际意图，并且可能大多数实现都做了正确的事情，因此我预计这个问题的优先级相当低，并且如果没有提议的措辞，它不太可能受到太多关注。当然，解决这个问题不会改变预期的行为，例如“扩大”char转换成 UTF8 序列：这实际上是对流库的重新设计，它可能是有序的，但不会作为缺陷解决的一部分来完成。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
