Такая методика работает во всех стандартных контейнерах и потому считается предпочтительным способом удаления элементов, определяемых итератором

.

Вероятно, вы уже поняли: говорить о том, что функция

класса возвращает «соответствующий» , не совсем правильно. В отношении вставки это действительно так, а в отношении удаления — нет. При преобразовании в важно знать, какие операции будут выполняться с полученным объектом . Только в этом случае вы сможете определить, подойдет ли он для ваших целей.

Предположим, вы хотите скопировать текстовый файл в объект

. На первый взгляд следующее решение выглядит вполне разумно:

Но вскоре выясняется, что приведенный синтаксис не копирует в строку пропуски (

), входящие в файл. Это объясняется тем, что производит непосредственное чтение функциями , а эти функции по умолчанию не читают пропуски.

Чтобы сохранить пропуски, входящие в файл, достаточно включить режим чтения пропусков сбросом флага

для входного потока:

Теперь все символы

копируются в .

Кроме того, может выясниться, что копирование происходит не так быстро, как вам хотелось бы. Функции

, от которых зависит работа , производят форматный ввод, а это означает, что каждый вызов сопровождается многочисленными служебными операциями. Они должны создать и уничтожить объекты (специальные объекты потоков ввода-вывода, выполняющие начальные и завершающие операции при каждом вызове ); они должны проверить состояние флагов, влияющих на их работу (таких, как ); они должны выполнить доскональную проверку ошибок чтения, а в случае обнаружения каких-либо проблем — проанализировать маску исключений потока и определить, нужно ли инициировать исключение. Все перечисленные операции действительно важны при форматном вводе, но если ваши потребности ограничиваются чтением следующего символа из входного потока, без них можно обойтись.

Более эффективное решение основано на использовании неприметного итератора

. Итераторы работают аналогично , но если объекты читают отдельные символы из входного потока оператором , то объекты обращаются прямо к буферу потока и непосредственно читают следующий символ (выражаясь точнее, объект читает следующий символ из входного потока вызовом ).

Перейти на использование

при чтении файла так просто, что даже программист Visual Basic сделает это со второй попытки:

На этот раз сбрасывать флаг skpws не нужно, итераторы

никогда не пропускают символы при вводе и просто возвращают следующий символ из буфера.

По сравнению с

это происходит относительно быстро. В проведенных мною простейших тестах выигрыш по скорости достигал 40%, хотя в вашем случае цифры могут быть другими. Не удивляйтесь, если быстродействие будет расти со временем; итераторы населяют один из заброшенных уголков STL, и авторы реализаций еще недостаточно позаботились об их оптимизации. Например, в моих примитивных тестах итераторы одной из реализаций работали всего на 5% быстрее, чем . В таких реализациях остается широкий простор для оптимизации .

Если вы планируете читать из потока по одному символу, не нуждаетесь в средствах форматирования ввода и следите за эффективностью выполняемых операций, три лишних символа на итератор — не такая уж дорогая цена за заметный рост быстродействия. При неформатном посимвольном вводе всегда рассматривайте возможность применения

.

Раз уж речь зашла о буферизованных итераторах, следует упомянуть и об использовании

при неформатном посимвольном выводе. По сравнению с итераторы обладают меньшими затратами (при меньших возможностях), поэтому обычно они превосходят их по эффективности.