随笔 - 5  文章 - 1  trackbacks - 0
<2024年11月>
272829303112
3456789
10111213141516
17181920212223
24252627282930
1234567

常用链接

留言簿(2)

随笔档案(5)

文章分类(3)

文章档案(3)

搜索

  •  

最新评论

阅读排行榜

评论排行榜

istream_iterators所依靠的operator<<函数进行的是格式化输入,这意味着每次你调用的时候它们都必须做大量工作。它们必须建立和销毁岗哨(sentry)对象(为每个operator<<调用进行建立和清除活动的特殊的iostream对象),它们必须检查可能影响它们行为的流标志(比如skipws),它们必须进行全面的读取错误检查,而且如果它们遇到问题,它们必须检查流的异常掩码来决定是否该抛出一个异常。如果进行格式化输入,那些都是重要的活动,但如果你需要的只是从输入流中抓取下一个字符,那就过度了。

一个更高效的方法是使用STL最好的秘密武器之一:istreambuf_iterators。你可以像istream_iterator一样使用istreambuf_iterator,但istream_iterator<char>对象使用operator<<来从输入流中读取单个字符。istreambuf_iterator<char>对象进入流的缓冲区并直接读取下一个字符。(更明确地说,一个istreambuf_iterator<char> 对象从一个istream s中读取会调用s.rdbuf()->sgetc()来读s的下一个字符。)把我们的文件读取代码改为使用istreambuf_iterator相当简单,大多数Visual Basic程序员都可以在两次尝试内做对:

ifstream inputFile("interestingData.txt");string fileData((istreambuf_iterator<char>(inputFile)),   istreambuf_iterator<char>());

注意这里不需要“unset”skipws标志,istreambuf_iterator不忽略任何字符。它们只抓取流缓冲区的下一个字符。

相对于istream_iterator,它们抓取得更快——在我进行的简单测试中能快40%,如果你的结果不同也不用惊奇。如果随时间流逝,速度优势不断增加也不必奇怪,因为istreambuf_iterator存在于STL的一个不常访问的角落,所以实现还没有花很多时间来优化。比如,在我用过的一个实现中,istreambuf_iterator在我的主要测试中只比istream_iterator快了大约5%。那样的实现显然还有很多余地来优化它们的istreambuf_iterator实现。如果你需要一个一个地读取流中的字符,你不需要格式化输入的威力,你关心的是它们花多少时间来读取流,和明显的性能提高相比,为每个迭代器多键入三个字符的代价是微弱的。对于无格式的一个一个字符输入,你总是应该考虑使用istreambuf_iterator。

当你了解它之后,你也应该考虑把ostreambuf_iterator用于相应的无格式一个一个字符输出的作。它们没有了ostream_iterator的开销(和弹性),所以它们通常也做得更好。

posted on 2007-06-08 09:46 Tempwmk 阅读(296) 评论(0)  编辑 收藏 引用

只有注册用户登录后才能发表评论。
网站导航: 博客园   IT新闻   BlogJava   知识库   博问   管理