是谁构建/设计了 C + + 的 IOStreams，以今天的标准来看，它是否仍然被认为是设计良好的？

如果你要根据今天的 软件工程标准(如 实际上有任何将军 这些协议) ，C + + 的 IOStreams 仍然被考虑 精心设计? (我可不想。) 提高我的软件设计技巧 通常被认为是 已经过时了。)

我会说 没有，有几个原因:

错误处理不当

错误条件应该与异常一起报告，而不是与 operator void*一起报告。

“僵尸对象”反模式是导致 像这样的虫子的原因。

格式化和 I/O 之间的差异

这使得流对象变得不必要的复杂，因为无论您是否需要，它们都必须包含额外的状态信息来进行格式化。

它还增加了写错误的几率，比如:

using namespace std; // I'm lazy.
cout << hex << setw(8) << setfill('0') << x << endl;
// Oops!  Forgot to set the stream back to decimal mode.

如果你写的是:

cout << pad(to_hex(x), 8, '0') << endl;

不会有与格式相关的状态位，也没有问题。

注意，在 Java、 C # 和 Python 等“现代”语言中，所有对象都有一个由 I/O 例程调用的 toString/ToString/__str__函数。AFAIK，只有 C + + 通过使用 stringstream作为转换为字符串的标准方法来完成相反的操作。

对 i18n 的支持不足

基于 Iostream 的输出将字符串文字拆分成多个部分。

cout << "My name is " << name << " and I am " << occupation << " from " << hometown << endl;

格式化字符串将整个句子放入字符串文字中。

printf("My name is %s and I am %s from %s.\n", name, occupation, hometown);

后一种方法更容易适应像 GNU gettext 这样的国际化库，因为使用完整的句子为翻译者提供了更多的上下文。如果字符串格式化例程支持重新排序(如 POSIX $ printf 参数) ，那么它还可以更好地处理语言之间的词序差异。

随着时间的推移，我对 C + + iostream 的看法已经有了很大的改善，特别是在我开始实际地通过实现我自己的 stream 类来扩展它们之后。我开始欣赏它的可扩展性和整体设计，尽管它的成员函数名如 xsputn或其他名称非常糟糕。无论如何，我认为 I/O 流是对 C stdio.h 的一个巨大改进，C stdio.h 没有类型安全，而且充满了主要的安全缺陷。

我认为 IO 流的主要问题在于它们混合了两个相关但有点正交的概念: 文本格式化和序列化。一方面，IO 流被设计用于生成对象的可读的、格式化的文本表示，另一方面，用于将对象序列化为可移植格式。有时候这两个目标是一样的，但是有时候这会导致一些非常恼人的不一致。例如:

std::stringstream ss;
std::string output_string = "Hello world";
ss << output_string;


...


std::string input_string;
ss >> input_string;
std::cout << input_string;

在这里，我们得到的输入是我们最初输出到流的 没有。这是因为 <<操作符输出整个字符串，而 >>操作符只从流中读取，直到遇到空白字符，因为流中没有存储 长度信息。因此，即使我们输出一个包含“ hello world”的字符串对象，我们也只会输入一个包含“ hello”的字符串对象。因此，虽然流已经发挥了格式化工具的作用，但它未能正确序列化然后取消序列化对象。

您可能会说 IO 流并不是为序列化设施而设计的，但是如果是这样的话，那么 输入流真正的用途是什么呢？此外，在实践中，I/O 流经常用于序列化对象，因为没有其他标准的序列化工具。考虑 boost::date_time或 boost::numeric::ublas::matrix，如果使用 <<运算符输出一个矩阵对象，那么当使用 >>运算符输入时，将得到相同的精确矩阵。但是为了实现这一点，Boost 设计人员不得不将列计数和行计数信息作为文本数据存储在输出中，这损害了实际的人类可读显示。同样，文本格式设置和序列化的笨拙组合。

请注意大多数其他语言是如何将这两种工具分开的。例如，在 Java 中，格式化是通过 toString()方法完成的，而序列化是通过 Serializable接口完成的。

在我看来，最好的解决方案是引入基于 字节的流，以及标准的基于 性格的流。这些流将对二进制数据进行操作，而不关心人类可读的格式化/显示。它们可以单独用作序列化/反序列化工具，将 C + + 对象转换为可移植的字节序列。

我情不自禁地回答了问题的第一部分(是谁干的?) ，但是其他的帖子也回答了这个问题。

至于问题的第二部分(设计得好吗?)我的回答是响亮的“不”.这里有一个小例子，多年来一直让我难以置信地摇摇头:

#include <stdint.h>
#include <iostream>
#include <vector>


// A small attempt in generic programming ;)
template <class _T>
void ShowVector( const char *title, const std::vector<_T> &v)
{
std::vector<_T>::const_iterator iter;
std::cout << title << " (" << v.size() << " elements): ";
for( iter = v.begin(); iter != v.end(); ++iter )
{
std::cout << (*iter) << " ";
}
std::cout << std::endl;
}
int main( int argc, const char * argv[] )
{
std::vector<uint8_t> byteVector;
std::vector<uint16_t> wordVector;
byteVector.push_back( 42 );
wordVector.push_back( 42 );
ShowVector( "Garbled bytes as characters output o.O", byteVector );
ShowVector( "With words, the numbers show as numbers.", wordVector );
return 0;
}

由于 iostream 的设计，上面的代码产生了一些无意义的东西。由于我无法理解的一些原因，它们将 uint8 _ t 字节视为字符，而将较大的整数类型视为数字。Q.E.D. 糟糕的设计。

我也想不出办法来解决这个问题。类型也可以是 float 或 double... ... 因此，为了让愚蠢的 iostream 明白数字而不是字符是主题，而将类型强制转换为“ int”是没有帮助的。

IOStream 的设计是有缺陷的，因为它没有给程序员一种方法来说明如何对待一个项目。IOStream 实现做出任意决策(比如将 uint8 _ t 视为字符，而不是字节数)。这是 IOStream 设计的一个缺陷，因为他们试图实现不可能实现的目标。

C + + 不允许对类型进行分类——该语言没有这种功能。IOStream 不可能使用 is _ number _ type ()或 is _ trait _ type ()这样的东西来做出合理的自动选择。忽略这一点，并试图逃避猜测是一个图书馆的设计缺陷。

承认，printf ()在通用的“ ShowVector ()”实现中同样无法工作。但这并不能成为我流行病学行为的借口。但是在 printf ()的例子中，ShowVector ()很可能是这样定义的:

template <class _T>
void ShowVector( const char *formatString, const char *title, const std::vector<_T> &v );

C + + iostream 有很多缺陷，就像其他回复中提到的那样，但是我还是想为它辩护一下。

C + + 在大量使用的语言中实际上是独一无二的，它使得变量的输入和输出对于初学者来说非常简单。在其他语言中，用户输入往往涉及类型强制或字符串格式化程序，而 C + + 让编译器完成所有工作。对于输出也是如此，尽管 C + + 在这方面并不是独一无二的。尽管如此，您仍然可以在 C + + 中很好地执行格式化 I/O，而不必理解类和面向对象的概念，这在教学上很有用，也不必理解格式化语法。同样，如果你是教初学者，这是一个很大的优势。

对于初学者来说，这种简单性是有代价的，在更复杂的情况下处理 I/O 会让人头疼，但希望到那时程序员已经学会了足够的知识来处理这些问题，或者至少已经到了喝酒的年龄。

当我使用 IOStream 的时候，总是会遇到惊喜。

这个库似乎是面向文本的，而不是面向二进制的。这可能是第一个惊喜: 在文件流中使用二进制标志不足以获得二进制行为。上面的用户 Charles Salvia 已经正确地观察到了这一点: IOStreams 混合了格式化方面(你想要漂亮的输出，例如浮点数的有限数字)和序列化方面(你不想要信息丢失)。也许把这些方面分开会比较好。加油。序列化完成这一半。您有一个序列化函数，如果需要，它可以路由到插入器和提取器。这两个方面之间已经有了张力。

许多函数也有混淆的语义(例如 get、 getline、忽略和 read)。有些提取分隔符，有些不提取; 还有一些设置 eof)。进一步说，在实现一个流(例如 xsputn、 uflow、 underflow)时，有些函数名很奇怪。如果使用 wchar _ t 变量，情况会变得更糟。Wifstream 执行到多字节的转换，而 wstringstream 不执行。使用 wchar _ t 时，二进制 I/O 不能立即工作: 您可以覆盖 codecvt。

C 缓冲的 I/O (即 FILE)不如它的 C + + 对应物那么强大，但是更加透明，并且有更少的违反直觉的行为。

但是每次我偶然发现 IOStream，我就像飞蛾扑火一样被它吸引住了。也许这将是一件好事，如果一些真正聪明的家伙会有一个好看的整体架构。