Эффективное использование STL

v.push_back(new Widget); // на динамически созданные объекты Widget

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

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

not1(mem_fun(&Widget::isCertified))). //Widget, непрошедшие v.end());// сертификацию.

// Информация о mem_fun

// приведена в совете 41.

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

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

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

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

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

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

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

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

void delAndNullifyUncertified(Widget*& pWidget) {

if(!pWidget()->isCertified()){ //Если объект *pWidget не сертифицирован,

delete pWidget; //удалить указатель

pWidget=0;//и присвоить ему null

}

for_each(v.begin(),.v.end(), // Удалить и обнулить все указатели на

delAndNullifyUncertified); // все указатели на объекты, не прошедшие

v.erase(remove(v.begin(),v.end(), // Удалить из v указатели null;

static_cast(0)), //0 преобразуется в указатель, чтобы С++

v.end()); //правильно определял тип третьего параметра

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

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

template class RCSP{..}; // RCSP = "Reference Counting Smart Pointer"

typedef RCSP RCSPW; // RCSPW = "RCSP to Widget"

vector v;

v.push_back(RCSPW(new Widget)):

v. erase(remove_if(v.begin() .v.end(),

not1(mem_fun(&Widget::isCertified))).

v.end()):