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

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

Передача в первом аргументе интервальной формы

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

Честно говоря, выбор имени

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

Как только вы поймете, что алгоритм

не может «по-настоящему» удалять объекты из контейнера, применение его в сочетании с войдет в привычку. Не забывайте, что — не единственный алгоритм, к которому относится это замечание. Существуют два других remove-подобных алгоритма: и .

Сходство между

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

Предположим, мы динамически создаем ряд объектов

и сохраняем полученные указатели в векторе:

Поработав с

в течение некоторого времени, вы решаете избавиться от объектов , не сертифицированных функцией , поскольку они вам не нужны. С учетом рекомендаций, приведенных в совете 43 (по возможности использовать алгоритмы вместо циклов), и того, что говорилось в совете 32 о связи и , возникает естественное желание использовать идиому , хотя в данном случае используется алгоритм :

Внезапно у вас возникает беспокойство по поводу вызова

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

Допустим, перед вызовом

вектор имеет следующий вид:

После вызова

вектор выглядит примерно так (с итератором, возвращаемым при вызове ):

Если подобное превращение кажется непонятным, обратитесь к совету 32, где подробно описано, что происходит при вызове

(в данном случае — ).

Причина утечки ресурсов очевидна. «Удаленные» указатели на объекты B и C были перезаписаны «оставшимися» указателями. На два объекта

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