谁设计/设计了C ++的IOStreams，并且按照当今的标准，它仍然被认为设计良好吗？[关闭]

首先，似乎我在征求主观意见，但这并不是我所追求的。我很想听听有关该主题的一些有充分根据的论点。

为了对如何设计现代流/序列化框架有所了解，我最近得到了Angelika Langer和Klaus Kreft撰写的《Standard C ++ IOStreams and Locales》一书的副本。我认为，如果IOStreams设计不当，那么它就不会首先进入C ++标准库。

在阅读了本书的各个部分之后，我开始怀疑IOStreams是否可以从总体体系结构的角度与STL进行比较。阅读例如对Alexander Stepanov（STL的“发明人”）的采访，以了解有关STL的一些设计决策。

特别令我惊讶的是：

• 谁来负责IOStreams的总体设计似乎是个未知数（我很想阅读有关此的一些背景信息-有人知道好的资源吗？）；

• 一旦你钻研输入输出流，例如眼前表面之下，如果你想输入输出流用自己的类扩展，你会得到一个接口具有相当神秘和扑朔迷离的成员函数的名称，例如getloc/ imbue，uflow/ underflow，snextc/ sbumpc/ sgetc/ sgetn，pbase/ pptr/ epptr（和有甚至更糟的例子）。这使得理解整体设计以及单个零件如何协作变得更加困难。即使我上面提到的那本书没有帮助那多（恕我直言）

因此，我的问题是：

如果你要判断今天的软件工程标准（如果确实是对这些任何普遍同意），将C ++的输入输出流仍然被认为是经过精心设计？（我不想通过通常认为过时的方法来提高软件设计技能。）

一些居心不良的想法找到自己的方式进入标准：auto_ptr，vector<bool>，valarray和export，仅举几例。因此，我不会将IOStreams的存在必然地视为质量设计的标志。

IOStreams具有历史记录。它们实际上是对早期流库的重做，但是它们是在不存在当今许多C ++惯用语的时候编写的，因此设计人员没有后见之明。随着时间的推移，一个显而易见的问题是，由于大量使用了虚函数并以最精细的粒度转发到内部缓冲区对象，几乎不可能像C的stdio一样高效地实现IOStreams。以定义和实现语言环境的方式。我承认，我对此的记忆非常模糊。我记得几年前它在comp.lang.c ++。moderated上引起了激烈的辩论。

关于由谁设计，最初的库由Bjarne Stroustrup创建（毫不奇怪），然后由Dave Presotto重新实现。然后，由Jerry Schwarz针对Cfront 2.0重新设计并重新实现，使用了来自Andrew Koenig的操纵器思想。库的标准版本基于此实现。

来源“ C ++的设计和演变”，第8.3.1节。

如果您必须根据当今的软件工程标准（如果实际上在这些标准上有任何一般性的协议）来判断，那么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的“现代”的语言，所有的对象有一个toString/ ToString/ __str__函数是由I / O函数调用。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参数），那么它也可以更好地处理语言之间的单词顺序差异。

我将其作为单独的答案发布，因为这是纯粹的意见。

执行输入和输出（尤其是输入）是一个非常非常棘手的问题，因此毫不奇怪，iostreams库中充满了很多障碍，而事后回想起来，它们本可以做得更好。但是在我看来，所有的I / O库，无论用哪种语言，都是这样的。我从来没有使用过一种编程语言，在这种语言中，I / O系统真是太美了，这让我对它的设计师感到敬畏。iostreams库确实具有优势，尤其是优于CI / O库（可扩展性，类型安全性等），但是我认为没有人将它作为出色的OO或通用设计的示例。

我对C ++ iostream的看法随着时间的流逝已经得到了很大的改善，特别是在我开始通过实现自己的流类来实际扩展它们之后。尽管成员函数的名称之类的荒谬可笑，我还是开始欣赏它的可扩展性和总体设计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 world”的字符串对象。因此，尽管流已将其用作格式化工具，但未能正确序列化该对象然后对其进行反序列化。

您可能会说IO流并非设计为序列化工具，但如果是这种情况，输入流的真正用途是什么？此外，实际上，由于没有其他标准的序列化工具，因此I / O流通常用于序列化对象。考虑到boost::date_time或boost::numeric::ublas::matrix，如果您使用<<运算符输出矩阵对象，则在使用运算符输入矩阵对象时会得到相同的精确矩阵>>。但是为了实现此目的，Boost设计人员必须将列数和行数信息作为文本数据存储在输出中，这损害了实际的人类可读显示。同样，文本格式设置工具和序列化的尴尬组合。

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

我认为，最好的解决方案是引入基于字节的流以及基于标准字符的流。这些流将对二进制数据进行操作，而无需考虑人类可读的格式/显示。它们可以仅用作序列化/反序列化工具，以将C ++对象转换为可移植字节序列。

我总是发现C ++ IOStreams设计不当：它们的实现使正确定义新类型的流变得非常困难。它们还混合了io功能和格式化功能（想想操纵器）。

就个人而言，我发现的最佳流设计和实现取决于Ada编程语言。它是去耦的模型，是创建新型流的一种乐趣，并且无论使用哪种流，输出功能始终有效。这要感谢一个最小公分母：您将字节输出到流，仅此而已。流函数负责将字节放入流中，而不是将整数格式化为十六进制（当然，定义了一组用于处理格式化的类型属性，等同于类成员）不是他们的工作。

我希望C ++对于流来说是如此简单...

我认为IOStreams设计在可扩展性和实用性方面非常出色。

1. 流缓冲区：看一下boost.iostream扩展：创建gzip，Tee，在几行中复制流，创建特殊的过滤器等等。没有它是不可能的。

2. 本地化集成和格式集成。看看可以做什么：

   std::cout << as::spellout << 100 << std::endl;

   可以打印：“一百”甚至：

   std::cout << translate("Good morning")  << std::endl;

   可以根据插入的语言环境打印“ Bonjour”或“בוקרטוב” std::cout！

   仅仅因为iostreams非常灵活，就可以做到这些事情。

可以做得更好吗？

当然可以！实际上，有很多事情可以改进...

今天，正确地从中派生是很痛苦的，stream_buffer添加其他格式信息以流式传输是很平常的，但是可能的。

但是，回顾多年前，我仍然很满意图书馆的设计，即将带来许多好处。

因为您可能无法始终看到全局，但是如果您为扩展留点，即使您没有想到的点也可以提供更好的能力。

（此答案仅基于我的意见）

我认为IOStreams比它们的功能等效要复杂得多。当我用C ++编写时，我仍然将cstdio标头用于“旧式” I / O，我发现它更可预测。附带说明（虽然不是很重要；绝对时间差可以忽略不计），IOStreams在许多情况下都比CI / O慢。

使用IOStream时，我总是会感到惊讶。

该库似乎是面向文本的，而不是面向二进制的。这可能是第一个惊喜：在文件流中使用二进制标志不足以获取二进制行为。上面的用户Charles Salvia正确地观察到了这一点：IOStreams将格式设置方面（您想要漂亮的输出，例如浮点数有限的地方）与序列化方面（您不想丢失信息的地方）混合在一起。分开这些方面可能会很好。Boost.Serialization完成了这一半。您具有序列化功能，可以根据需要路由到插入器和提取器。您已经在这两个方面之间产生了张力。

许多函数的语义也令人困惑（例如，get，getline，ignore和read。有些提取定界符，有些则不提取分隔符，还有一些设置eof）。进一步提到在实现流时奇怪的函数名称（例如xsputn，uflow，下溢）。当使用wchar_t变体时，情况变得更糟。wifstream会转换为多字节，而wstringstream不会。wchar_t不能立即使用二进制I / O：您已经覆盖了编解码器。

C缓冲的I / O（即FILE）没有C ++缓冲的I / O强大，但更透明，反直观行为更少。

仍然，每当我偶然发现IOStream时，都会像飞蛾一样被它吸引住。如果某些非常聪明的人对整体体系结构有一个很好的了解，那可能是一件好事。

我不禁回答问题的第一部分（谁做的？）。但这在其他帖子中得到了回答。

关于问题的第二部分（设计得好吗？），我的回答是响亮的“不！”。这是一个小例子，多年来使我难以置信：

#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字节视为字符，而较大的整数类型则视为数字。Qed不良设计。

我也没有办法解决此问题。该类型也可以是浮点数或双精度数...因此强制转换为“ int”以使傻傻的iostream理解数字而不是字符是主题将无济于事。

在收到对我的答复的不赞成票之后，也许还有更多的解释……IOStream设计存在缺陷，因为它没有给程序员一种陈述项目如何处理的方式。IOStream实现可以做出任意决定（例如将uint8_t视为一个字符，而不是一个字节数）。这是IOStream设计的缺陷，因为他们试图实现无法实现的目标。

C ++不允许对类型进行分类-语言没有功能。IOStream不能使用is_number_type（）或is_character_type（）这样的东西来做出合理的自动选择。忽略这一点并试图摆脱猜测是图书馆的设计缺陷。

公认的是，printf（）同样无法在通用的“ ShowVector（）”实现中工作。但这不是iostream行为的借口。但是很有可能在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感到头疼，但是希望到那时，程序员已经学到了足够的知识来处理它们，或者至少变老了。喝