突然觉得C++ IOStreams库有点奇怪

[fixopen]

IOStreams是C++标准库的一部分，占了1/3的分量（另外STL占了1/3，其余杂项总和占了1/3）。不能不说是很大的一块。
一直以来很欣赏IOStreams的结构，觉得非常优雅，可是近来突然发现，我们有必要搞出iostream，fstream和stringstream这三套流么？采用不同的底层stream_buf有什么问题？分成三种的优势是什么？

[htqx]

其实Html有个标记,用于代码可以保持缩进的, 为何csdn的开发者不使用?

[iu_81]

try to do

[lidongri]

我们有必要搞出iostream，fstream和stringstream这三套流么？采用不同的底层stream_buf有什么问题？分成三种的优势是什么？

术业有专攻
虽然每一部分都有一些相似的地方
但大部分还是不一样的,实现的方面是不同的

[agaric]

.. 對行爲的抽象，你在使用的時候可以不用太關心具體是造作的哪一種stream

[天堂里的死神]

这是问题吗？
iostream和fstream分开是可以理解的，设备不同
fstream和stringstream分开也是可以理解的，操作对象不同
有什么不好理解的？
iostream调用open(filename)是什么概念？
stringstream调用is_open是什么意思？
设计或许不优雅，但是很实用，很质朴，很面向本质
个人见解

[phisherr]

收藏

[fixopen]

〉〉〉
这是问题吗？
iostream和fstream分开是可以理解的，设备不同
fstream和stringstream分开也是可以理解的，操作对象不同
有什么不好理解的？
iostream调用open(filename)是什么概念？
stringstream调用is_open是什么意思？
设计或许不优雅，但是很实用，很质朴，很面向本质
个人见解
〉〉〉

可是你真的觉得OPEN是格式化层关注的事情？你不觉得OPEN跟传输层关系密切？

[天堂里的死神]

那就花时间解释：
“
恩，其实呢，是这个原因：Open( filename )不是打开一个文件，而是打开一个Stream。所以，stringstream这样调用也是可以滴～～相同，stringstream调用is_open也是可以的。
”
C＋＋初学者全体倒地……一个字：“晕”哦！

^_^开个玩笑，我的意思是，人们一看file直接就能想到open和close，这其实只不过是一个叫名问题，传输层的，可以换个名字叫做__open或者别的名字，但是，接口设计的一个重要原则是直观，如果看到一个类的方法就能猜到他是什么意思，何必引入不必要的复杂度，仅仅是为了“优雅”呢？ ^_^
新年愉快。

[healer_kx]

我也觉得怪，接分。

[rularys]

新年快乐！

[fixopen]

其实这个问题已经好长时间了，由于近一段时间对无格式的IO思考了一番，发觉了一些有感于心的东西，决定写出来，供大家评判。

C++的std IOStreams发源于IOStreams，IOStreams发源于streams，那是BS教主的作品，最初也是分为两个层次，一个是stream，一个是stream_buf，当时的分工其实很简单，stream是主体，主要的功能完成区域，stream_buf干一些细节性的事物。由于streams是面向字符的流，所以其实其主要功能是解析和格式化，也就是把某些内部对象转换为外部字符串或者相反的转化。它比C的printf和scanf强的地方有两个：一、类型安全，二、扩展方便。后来被改写为IOStreams，作者认为stream_buf不应该是一个无关紧要，无关痛痒的细节性的东西，而应该能完成实实在在的工作。作者的责任分派是这样的：stream完成解析和格式化，叫做格式化层次，stream_buf完成真正的设备（或文件）传输，同时肩负编码转换、缓冲等附加功能。由此就有了我的疑问。

如果我们不考虑面向字符的流，而是单纯的考虑流，显然，解析和格式化并不是必须的，反倒是真正的传输是必须的，解析和格式化不过是一个针对字节流而引入的一个功能而已。那么，流本身应该是什么样子的？显然，有read write或者<< >>足矣。至于解析（包括文本的国际化和格式的本地化），至于缓冲，至于编码转化，显然是根据需要插入的一些插件，甚至在没有预留插件接口的时候通过AOP（或者叫做Interceptor）的方式也可以搞定。

现在大家感觉出来C++Std IOStreams别扭的地方了没有？本来格式化层只想提供解析和格式化的功能，本来可以只有一个格式化设备应用到所有的流上面，可是不得已只得派生好多，并且要在该层加入open之类的根本毫不相干的东西，只是为了把stream_buf层的功能暴露出来而不让用户接触stream_buf（这个一度被认为是细节的不应该暴露的设施）。

[wingfiring]

楼上分析的不错．

[不想低调]

先jf，慢慢看

[eplanet]

学习了

这个不错

希望下次还有别的

[thinkinnight]

这个讨论很好，收藏一下，对于流，使用的时候是很方便，但是还是不喜欢模板，现在编译器对模板的支持已经变好了，但是调试的时候还是麻烦，编译时出错看出错代码也感觉烦

[晨星]

同意fixopen的最后一次回复。

同时鄙视一下7个半月不结帖的。

[guanwl]

留名

[晨星]

再来顶一下。发现fixopen这次确实说到点子上了，嘿嘿。
人家Java标准库中的那一套“Stream”就没有任何“格式化”的功能，甚至那一套相应的Reader/Writer类也没有。
即使那种“readInt”名字上看起来像的，实际上也不是，人家所进行的也是直接的二进制提取而非字符串转换。
而要完成字符串到其它类型的转换，在Java中是其它一些类自己的功能，比如Integer.parseInt，Integer.valueOf等等。

[thinkinnight]

看了晨星的点评，又细细看了一下fixopen的那一大段，(*^__^*) ，昨晚没看仔细
说得不错，是作者将其复杂化了，本来就考虑流的话，就不用这么麻烦了。
但是最后一段没看懂

“现在大家感觉出来C++Std IOStreams别扭的地方了没有？本来格式化层只想提供解析和格式化的功能，本来可以只有一个格式化设备应用到所有的流上面，可是不得已只得派生好多，并且要在该层加入open之类的根本毫不相干的东西，只是为了把stream_buf层的功能暴露出来而不让用户接触stream_buf（这个一度被认为是细节的不应该暴露的设施）。”

是说stream_buf这层是一致的，但是因为stream层要对不同的字符对象进行解析，从而派生出很多的iostream,fstream,stringstream的意思吗？

[KenYuan2016]

IOstream 功能非常多，从它基层过来的ifstream等，文件操作流，很好用。