C ++ Streams与.NET Streams相比？

Question

标准库是否仍然使用它所做的流？似乎.net流更容易使用和实现。由于兼容性的原因，我可以理解他们保留它们，但为什么他们没有添加更像.net？

的新流实现

与.NET流相比，C ++流有哪些优缺点？我无法想出任何C ++流的专业人士：。

像nos所述
“他正在讨论的概念不是MS实现。替代例如.NET for Java，问题意味着几乎相同（因为它的流的概念类似于.NET的概念，但与C ++不同）”

Answer 1

虽然它们都遵循基本抽象，但C ++和.NET以不同的方式解释“流”。考虑到这一点，将.NET的Stream与C ++的*stream进行比较是不公平的，因为它们用于不同的目的：一个用于将字节移入和移出存储，另一个用于帮助数据表示。然而，两个框架在另一个框架中都有类似物：

• .NET：Stream：*Reader
• C ++：streambuf：iostream

关于C ++方面，请查看GNU C++ Iostream docs中的这句话，它比我说得好：

  

istream和ostream类用于处理程序中对象与文本表示之间的转换。

     

相比之下，底层streambuf类用于在程序，输入源或输出接收器之间传输原始字节。

我认为当你进行适当的比较时，你会发现事情更有意义。 （Stream与streambuf的会员列表非常相似，TextReader和istream也是如此。）

Answer 2

C ++流是C ++的一个古老功能，现在改变它们将是令人望而却步的。这并不意味着它们无法改进，但它们不会被替换。没有任何人接近C ++标准委员会会建议添加并行流实现。这会给有限的利益带来很大的困惑。

话虽如此，.NET流的优点是什么？我是一个C ++人，对.NET的接触有限。我同意C ++流可以很笨拙，但它们通常可以毫不费力地完成工作。 .NET流如何证明C ++的重大改变是正确的？

Answer 3

我不知道.Net，但是既然你说Java流的问题是相同的，那么最明显的C ++流程就是它们拥有内置于std :: ios的所有格式。您可以合理地认为这与分流字节的业务正交，因此应该是一个单独的问题。然后C ++再次将两者分开，（参见streambuf）只是它发生在调用流中的事情也是格式化的事情，而Java将简单的事情称为流，然后程序员用扫描仪，读者或其他东西装饰它。

像往常一样，Java提供了一个简单的界面，C ++提供了一个“高度可配置且功能非常强大”的界面，这种界面非常繁琐。易用性并不是C ++标准委员会唯一关注的问题。

至于为什么委员会没有像微软在.NET中那样提供类似Java的替代API，我怀疑：

• 委员会更愿意让第三方做这种适配器工作。
• 委员会喜欢当前API的许多方面，例如operator<<和operator>>的通用重载。我不确定这是否是你不喜欢C ++流的一部分，但它肯定是喜欢它们的人的一部分，就像他们一样。

无论如何，自从C ++标准首次发布以来，实际上并未对C ++标准进行过重大更新，因此即使委员会想要进行更改（它不是AFAIK），它现在仍然只是草稿形式可能会在今年，也许是明年发布。

Answer 4

C ++流从一开始就设计得很糟糕。太糟糕了，很多人都使用它来编写代码，并且不可能从标准中删除它。难以扩展（尝试向流添加压缩或加密功能是一场噩梦）。

多年来使用C ++流程后，我不再在任何新项目中使用它。 Google Coding Guidelines同意我的意见。它说“仅使用流来记录”。