Почему erase в цикле часто ошибочен

1. Введение

Давайте начнём с честного признания: удалить элементы «на ходу» хочется всегда. У вас есть список задач, список чисел, список строк — и вы хотите «выкинуть мусор»: пустые строки, выполненные задачи, отрицательные значения, что угодно. Интуитивно кажется, что это ровно одна строчка: «если не нравится — erase». А раз мы уже умеем for и if, то что может пойти не так?

Проблема в том, что цикл и erase пытаются управлять одним и тем же процессом — перемещением по контейнеру — но делают это по разным правилам. Цикл считает, что вы идёте по стабильной «линейке» элементов. erase же прямо во время обхода выдёргивает одну «плитку» и сдвигает все следующие, чтобы закрыть дырку. В результате «следующий элемент» в голове цикла и «следующий элемент» в реальном контейнере могут внезапно оказаться разными сущностями.

Чтобы было проще держать всё в голове, будем представлять, что мы пишем маленькое консольное приложение TaskBook: у нас есть std::vector задач, и периодически нам надо очищать список от выполненных задач или от задач с пустым названием.

2. Как работает vector::erase

Прежде чем ругать анти‑паттерны, давайте спокойно разберёмся, что именно делает erase. Не как «внутри реализации», а как это выглядит логически: один элемент исчезает, все элементы справа сдвигаются влево на одну позицию, размер уменьшается на 1, а итераторы/ссылки на затронутые элементы становятся проблемными.

Посмотрим на это на примере. Пусть есть числа, чтобы не отвлекаться:

Удаляем элемент по индексу 1 (то есть 20). После erase:

То есть «то, что было 30», теперь живёт там, где раньше была 20. Поэтому если ваш цикл «собирался» после удаления сделать ++it или i++, то он почти гарантированно перескочит через 30, потому что 30 уже переехал на позицию удалённого.

Вот простая схема (не про память, а про смысл):

flowchart LR
    A["Идём по элементам"] --> B{"Условие удалить?"}
    B -->|нет| C["Сделать шаг дальше"]
    B -->|да| D["erase: убрать элемент"]
    D --> E["Сдвиг хвоста влево"]
    E --> F["Размер уменьшился"]
    F --> A

И ключевой момент: после erase прежние «ориентиры» для продолжения обхода могут стать неправильными. Поэтому у erase есть важный контракт: он возвращает итератор на элемент, который стал «следующим» после удалённого. Если вы этот итератор игнорируете, вы почти всегда идёте по минному полю.

3. Мини‑база TaskBook для примеров

Чтобы примеры не были набором случайных vector<int>, зададим минимальную модель задачи. Да, это маленький фрагмент «приложения», но нам важно, чтобы дальше в примерах мы удаляли не абстрактные числа, а что‑то похожее на реальную программу.

#include <string>

struct Task {
    int id{};
    std::string title;
    bool done{};
};

И ещё одна утилита, чтобы быстро видеть результат (в реальном проекте вы бы вынесли это в отдельную функцию, но сейчас держим коротко):

#include <iostream>
#include <vector>

void print_ids(const std::vector<Task>& tasks) {
    for (const auto& t : tasks) std::cout << t.id << ' ';
    std::cout << '\n';
}

Дальше мы будем рассматривать разные «способы удалить выполненные задачи» и смотреть, где именно мозг человека и поведение vector расходятся во мнениях.

4. Анти‑паттерны: erase во время обхода

erase внутри range‑for

Range‑for выглядит как подарок судьбы: минимум кода, максимум читаемости. И поэтому он самый популярный кандидат на «а давайте прямо тут и удалять». Логика новичка простая: раз я получил Task& t, то сейчас проверю t.done и удалю. Увы, range‑for внутри себя использует итераторы, и вы не контролируете, что происходит с ними после изменения контейнера.

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

#include <vector>

void remove_done_bad(std::vector<Task>& tasks) {
    for (Task& t : tasks) {
        if (t.done) {
            // ПЛОХО: range-for скрывает итераторы,
            // а erase их инвалидирует.
            // tasks.erase(...);
        }
    }
}

Почему это плохо именно концептуально? Потому что range‑for думает: «я сейчас буду последовательно двигаться от begin к end». А вы в середине маршрута вырываете кусок дороги и перекладываете асфальт. Итератор, который «обслуживает» цикл, может стать невалидным. Даже если «у вас вроде работает», это тот самый случай «работает до первого релиза».

Правильная мораль не в том, что range‑for плох. Он отличный, когда вы не меняете контейнер, а только читаете или меняете элементы на месте (например, поправить поле done, заменить строку и т.п.). Но удаление элементов — это уже изменение структуры контейнера, и здесь range‑for чаще мешает, чем помогает.

for (it ... ++it) + erase(it) без переназначения

Этот вариант выглядит «умнее», потому что мы используем итераторы явно. Новичок пишет примерно так: «иду итератором, если элемент плохой — удаляю». И даже знает, что erase существует. Но он не учитывает два эффекта одновременно: erase инвалидирует текущий итератор, а for в заголовке всё равно делает ++it.

Плохой пример (опасную строку снова комментирую, потому что это классическая ловушка):

#include <vector>

void remove_done_bad2(std::vector<Task>& tasks) {
    for (auto it = tasks.begin(); it != tasks.end(); ++it) {
        if (it->done) {
            // ПЛОХО: erase инвалидирует it,
            // а потом цикл сделает ++it по "сломавшемуся" it.
            // tasks.erase(it);
        }
    }
}

Даже если вы «случайно» не упали по невалидному итератору, вы часто получите пропуск элементов. Представьте, что рядом стоят две выполненные задачи подряд. Вы удалили первую, вторая сдвинулась на её место, а цикл потом ещё и ++it сделал — и вторая задача не проверилась вообще. Получается фильтр «удалять каждую вторую подходящую», что, конечно, очень инновационно, но обычно не то, что вы хотели.

Нормальная стратегия здесь одна: если вы удаляете, вы обязаны взять новый итератор, который вернул erase, и не делать дополнительный шаг. Обычно это выглядит как «цикл без ++it в заголовке». Но сам паттерн мы аккуратно доведём до «красивого вида» уже в соседних лекциях; сегодня нам важно понять, почему «наивный» вариант часто ломается.

Индексный цикл и erase(begin() + i)

Если итераторы кажутся сложными, следующая идея звучит очень по‑человечески: «я же умею индексы, vector[i], значит сделаю обычный for по i и удалю tasks.begin() + i». И это снова выглядит логично… ровно до первой реально удалённой позиции, после которой индексы элементов меняются.

Вот типичный плохой вариант:

#include <vector>

void remove_done_bad3(std::vector<Task>& tasks) {
    for (size_t i = 0; i < tasks.size(); ++i) {
        if (tasks[i].done) {
            tasks.erase(tasks.begin() + static_cast<long long>(i));
        }
    }
}

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

Есть и второй, менее очевидный «подарок»: каждый erase в середине vector сдвигает хвост, то есть чем больше удалений — тем больше сдвигов. Интуитивно это превращает простой фильтр в штуку, которая может стать заметно медленнее на больших данных.

Иногда люди пытаются «лечить» это проходом с конца в начало: если удалять справа налево, сдвиги не ломают уже обработанные индексы. Но там вас ждёт отдельная ловушка с size_t и уходом в бесконечный цикл (потому что size_t — беззнаковый тип, и «минус один» превращается в огромное число). Мы не будем сейчас делать из этого отдельный урок, но важно хотя бы знать: «обратный цикл по size_t» — один из самых популярных способов случайно написать вечный двигатель.

Попытка «зафиксировать» end() или сохранить ссылку/указатель

Когда вы впервые слышите про инвалидацию, возникает естественное желание «обойти» её: «хорошо, итераторы ломаются… тогда я сохраню end заранее», или «я сохраню ссылку на текущий элемент, а потом удалю». Это кажется экономным и аккуратным, но у vector это очень часто приводит к тому, что вы используете объект, который больше не имеет отношения к текущей реальности контейнера.

Пример с «сохраню end()»:

#include <vector>

void remove_done_bad4(std::vector<Task>& tasks) {
    auto last = tasks.end(); // ПЛОХАЯ идея: end() может стать невалидным
    for (auto it = tasks.begin(); it != last; ++it) {
        if (it->done) {
            tasks.erase(it);  // здесь last тоже "под вопросом"
            break;
        }
    }
}

Да, кажется, что end() — это «просто граница». Но у vector после модификации контейнера граница меняется, и сохранённый last может перестать быть корректной границей. Это один из тех случаев, когда код «иногда работает», потому что случайно не попал в плохую комбинацию данных.

Пример с «сохраню ссылку» тоже звучит красиво, но на деле опасен:

#include <vector>

void bad_ref(std::vector<Task>& tasks) {
    Task& ref = tasks[0];
    tasks.erase(tasks.begin()); // ref теперь может ссылаться "не туда"
    // ref.id; // опасно использовать
}

Ссылки и указатели на элементы vector привязаны к конкретным позициям в массиве. А erase эти позиции меняет: сдвигает элементы, уничтожает удалённый, иногда перемещает объекты. Поэтому «ссылка на элемент» и «удаление элемента» — почти всегда конфликт интересов.

И да, это ровно то место, где многие впервые встречают неприятную философию C++: «если ты сделал небезопасное — компилятор не обязан тебя спасать». Даже рабочая группа стандарта периодически разбирает нюансы erase-подобных операций и их контрактов — не потому что им скучно, а потому что тема реально тонкая.

Много одиночных erase и внезапное O(N²)

Есть особый вид боли: когда код логически «почти правильный», иногда даже корректный, но внезапно начинает тормозить. Типичный сценарий: у вас 100000 задач, и вы хотите удалить все выполненные. Вы пишете цикл и делаете erase каждый раз, когда видите done. На маленьких данных всё летает. На больших — внезапно «почему так долго?».

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

Вот «плохая по стоимости» идея в форме, которую легко встретить:

#include <vector>

void remove_done_slow(std::vector<Task>& tasks) {
    for (auto it = tasks.begin(); it != tasks.end(); ++it) {
        if (it->done) {
            tasks.erase(it); // даже если “чинить” итератор, сдвиги всё равно дорогие
            break;
        }
    }
}

Здесь я специально не показываю «как правильно переписать», потому что массовая чистка уже обсуждалась как отдельная идиома (и мы ещё закрепим её дальше по курсу). Главное ощущение сегодняшней лекции: много одиночных erase внутри длинного обхода почти всегда подозрительно, даже если вы аккуратно чините итераторы.

5. Шпаргалка: как думать перед удалением

Когда вы в следующий раз захотите удалить элементы из std::vector, попробуйте поймать себя на паузе на 2 секунды и задать один вопрос: «я удаляю один элемент или много?». Если вы удаляете много по условию, почти всегда хочется не «выдёргивать по одному в цикле», а применить подход, который делает минимум сдвигов и не ломает обход. Если вы удаляете точечно «в процессе обхода», вам нужен такой паттерн цикла, где шаг итератора контролируется вручную, и где после удаления вы продолжаете с итератора, который вернул erase.

И ещё одно правило, которое экономит часы жизни: если код удаляет из vector прямо внутри range‑for по этому же vector, то он почти наверняка неправильный. Иногда это можно сделать «так, что работает», но это уже не уровень начинающего курса, а уровень «я готов объяснить этот трюк другому человеку и не покраснеть».

Смысл сегодняшней лекции не в том, чтобы вы запомнили «правильную магическую строчку», а в том, чтобы вы узнали анти‑паттерны в лицо. Когда вы их узнаёте, вы автоматически перестаёте писать хрупкий код «на удачу» и начинаете писать код «по контракту контейнера».

6. Типичные ошибки

Ошибка №1: удаление из std::vector внутри range‑for по этому же vector.
Range‑for выглядит безопасно, но он скрывает итераторы. Когда вы делаете erase, вы меняете контейнер и можете инвалидировать итератор, которым range‑for управляет изнутри. В лучшем случае вы получите пропуски элементов, в худшем — неопределённое поведение.

Ошибка №2: erase(it) внутри for (...; ++it) без переназначения итератора.
Здесь два удара подряд: erase делает it невалидным, а заголовок цикла всё равно пытается сделать ++it. Даже если программа «не упала», она часто пропускает элементы, особенно если подходящие к удалению стоят подряд.

Ошибка №3: индексный цикл for (i...) + erase(begin()+i) и наивное i++.
После удаления элемент справа сдвигается влево на текущий индекс i, а вы увеличиваете i и перескакиваете через него. В результате удаляется не всё, что должно. Дополнительно вы получаете много сдвигов хвоста, и на больших данных код начинает заметно тормозить.

Ошибка №4: попытка «зафиксировать» границы обхода (end()) или сохранить ссылки/указатели на элементы, а потом менять контейнер.
У vector любое изменение, связанное со сдвигом элементов, делает сохранённые привязки ненадёжными. end() после удаления — уже не тот end(), а ссылка на элемент после erase может начать указывать на другой объект или стать вообще опасной для использования.

Ошибка №5: много одиночных erase как способ массовой фильтрации.
Даже если вы аккуратно обходите контейнер и не ломаете итераторы, частые erase в середине vector порождают множественные сдвиги элементов. По ощущениям это быстро превращается в «слишком долго», хотя логика вроде бы простая. В таких задачах нужно выбирать способ удаления, который рассчитан на массовую чистку, а не на точечные выдёргивания.