У подобного решения имеется недостаток — необходимость копирования элементов, остающихся после удаления. Такое копирование может обойтись дороже, чем нам хотелось бы.

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

, придется перебирать все элементы с в цикле и принимать решение об удалении текущего элемента.

С концептуальной точки зрения эта задача несложна, да и реализуется она просто. К сожалению, решение, которое первым приходит в голову, редко бывает правильным. Вероятно, многие программисты предложат следующий вариант:

Выполнение этого фрагмента приводит к непредсказуемым результатам. При стирании элемента контейнера все итераторы, указывающие на этот элемент, становятся недействительными. Таким образом, после возврата из

итератор становится недействительным. Для нашего цикла это фатально, поскольку после вызова итератор увеличивается ( в заголовке цикла ).

Проблема решается просто: необходимо позаботиться о том, чтобы итератор переводился на следующий элемент с перед вызовом

. Это проще всего сделать постфиксным увеличением i при вызове:

Новый вариант вызова

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

Пора сделать следующий шаг. Помимо простого удаления всех элементов, для которых

возвращает , мы также хотим регистрировать каждую операцию удаления в журнале.

Для ассоциативных контейнеров задача решается очень просто, поскольку она требует лишь тривиальной модификации созданного цикла:

На этот раз хлопоты возникают с

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