C++ 里面的不常用的iterator

1.操作 iteraor 的两个函数 advance distance 

   advance 用来 对迭代器进行 + -，只是各种迭代器的 +- 不同

  distance 用来获取来个迭代器直接的元素数量

2  back_inserter 是iterator适配器，它使得元素被插入到作为实参的某种容器的尾部，如vector等

back_inserter生成一个绑定在该容器上的插入迭代器，在试图通过该迭代器给元素赋值时，赋值运算符将调用push_back添加一个具有指定值的元素

front_inserter 则是调用 push_front 原理同上

Inserter 则是在容器指定位置插入元素 但是容器必须提供insert 函数

 必须要提到的一点是，这三种迭代器是对容器有要求的，分别要求容器提供insert，push_back，push_front方法才行

3 reverse_iterator逆向迭代器

4标准程序库定义有供输入及输出用的iostream iterator类，称为istream_iterator和ostream_iterator，分别支持单一型别的元素读取和写入。

5假设我们要把一个文本文件拷贝到一个字符串对象中。似乎可以用一种很有道理的方法完成

ifstream inputFile("interestingData.txt");

string fileData((istream_iterator<char>(inputFile)),

istream_iterator<char>()); // fileData；关

很快你就会发现这种方法无法把文件中的空格拷贝到字符串中。那是因为istream_iterators使用operator<<函数来进行真的读取，而且operator<<函数在默认情况下忽略空格。假如你想保留空格，你要的做就是覆盖默认情况。只要清除输入流的skipws标志就行了：

ifstream inputFile("interestingData.txt");inputFile.unset(ios::skipws);    // 关闭inputFile的       // 忽略空格标志string fileData((istream_iterator<char>(inputFile)), istream_iterator<char>());

现在inputFile中的所有字符都拷贝到fileData中了。

唉，你会发现它们的拷贝速度不像你想象的那么快。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的开销（和弹性），所以它们通常也做得更好。