Чтение онлайн

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

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

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

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

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

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

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

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

Поработав с

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

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

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

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

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

После вызова

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

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

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

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

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

После выполнения

и ситуация выглядит следующим образом:

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

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

Если без

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

Приведенное решение предполагает, что вектор не содержит

– указателей, которые бы требовалось сохранить. В противном случае вам, вероятно, придется написать собственный цикл, который будет удалять указатели в процессе перебора. Удаление элементов из контейнера в процессе перебора связано с некоторыми тонкостями, поэтому перед реализацией этого решения желательно прочитать совет 9.