мы живем, не идеален, но другого все равно нет. Как упоминается в совете 44, для контейнеров 1 i st вызов функции remove более эффективен, чем применение идиомы erase/remove.

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

Сходство между remove и removei f настолько прямолинейно, что я не буду на нем останавливаться, но алгоритм unique тоже похож на remove. Он предназначен для удаления смежных повторяющихся значений из интервала без доступа к контейнеру, содержащему элементы интервала. Следовательно, если вы хотите действительно удалить элементы из контейнера, вызов unique должен сопровождаться парным вызовом erase. В контейнере 1 i st также предусмотрена функция uni que, производящая фактическое удаление смежных дубликатов. По эффективности она превосходит связку erase-unique.

Совет 33. Будьте внимательны

при использовании remove-подобных

алгоритмов с контейнерами указателей

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

class Widget { public:

bool isCertifiedO const: Функция сертификации объектов Widget

vector<Widget*> v: Создать вектор и заполнить его указателями

на динамически созданные объекты Widget

v.push back(new Widget):

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

v.erase(removeJf(v.begin(), v.endO. Удалить указатели на объекты

notl(mem fun(&Widget::isCertified))). Widget, не прошедшие V.endO): сертификацию.

Информация о meffl fun приведена в совете 41.

Внезапно у вас возникает беспокойство по поводу вызова erase, поскольку вам смутно припоминается совет 7 - уничтожение указателя в контейнере не приво-

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

Допустим, перед вызовом reinove i f вектор v имеет следующий вид:

V.beginO

V.endO

Widget В Объект не сертифицирован

Widget С Объект не сертифицирован

Widget D

Widget Е

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

V.beginO

Возвращаемое

значение->

rennovejf

V.endO

Если подобное превращение кажется непонятным, обратитесь к совету 32, где подробно описано, что происходит при вызове renrave (в данном случае - remove i f).

Причина утечки ресурсов очевидна. Удаленные указатели на объекты В и С были перезаписаны оставшимися указателями. На два объекта Widget не существует ни одного указателя, они никогда не будут удалены, а занимаемая ими память расходуется впустую.

После выполнения remove if и erase ситуация выглядит следующим образом:

V.beginO

V.endO

Widget В

Widget С

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

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

void delAndNullifyUncertified(Widget*& pWidget)

i f(!pWi dgetO->i sCerti fi ed()){ delete pWidget; pWidget=0:

Если объект *pWidget

не сертифицирован.

удалить указатель

и присвоить ему null

for each(v.begin() .V.endO.

del AndNul1i fyUncerti fied);

V.era se(remove(v.begi n().v.end(),

static cast<Widget*>(0)), V.endO):

Удалить и обнулить все указатели на объекты, не прошедшие сертификацию. Удалить из V указатели null: О преобразуется в указатель, чтобы С++ правильно определял тип третьего параметра

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

Если контейнер зтсазателей заменяется контейнером г/лныг указателей с подсчетом ссылок, то все трудности, связанные с remove, исчезают, а идиома erase-remove может использоваться непосредственно:

tempi ate<typenanie Т> class RCSP{. };

typedef RCSP<Widget> RCSPW;

vector<RCSPW> v:

v.push back(RCSPW(new Widget)):

RCSP = Reference Counting Smart Pointer

RCSPW = RCSP to Widget

Создать вектор и заполнить его умными указателями на динамически созданные объекты Widget

v.erase(remove if(v.begin() .V.endO,

not1(mem fun(&Wi dget::i sCerti fi ed))),

V.endO):

Удалить указатели на объекты Widget, не прошедшие сертификацию. Утечка ресурсов отсутствует!

Чтобы этот фрагмент работал, тип умного указателя (например, RCSP<Widget>) должен преобразовываться в соответствующий тип встроенного указателя (например Widget*). Дело в том, что контейнер содержит умные указатели, но вызываемая функция (например Widget: risCertified) работает только со встроенными указателями. Если автоматическое преобразование невозможно, компилятор выдаст сообщение об ошибке.