Алгоритм vs цикл

1. Контекст и критерии выбора

Когда вы только научились писать for и while, возникает естественное ощущение: «Зачем мне вообще эти std::find_if и друзья, если я могу честно написать цикл и всё сделать сам?». И это ощущение абсолютно нормальное: цикл — это универсальный швейцарский нож, которым можно и бутерброд нарезать, и системный блок открыть (второе — не рекомендую, гарантия обидится).

Но у универсальности есть цена: ручной цикл почти всегда приносит с собой «шум» — счётчики, флаги, break, границы, риск off-by-one, забытые инициализации и прочие маленькие ловушки. Алгоритм же — это попытка выразить намерение: не «как именно я шагаю по элементам», а «что я хочу узнать/сделать». В этой лекции мы научимся выбирать подход не по религии («алгоритмы святы» / «циклы честнее»), а по читаемости и прозрачности поведения.

Читаемость и прозрачность: два разных качества кода

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

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

Наша мини-история: учебное приложение TaskTracker

Чтобы сравнение не было абстрактным, будем держать в голове простую модель: список задач. Мы не будем усложнять ввод/парсинг и не будем делать «настоящий продукт» — просто маленький контекст, в котором естественно возникают вопросы «где? сколько? есть ли? все ли?».

Вот базовая модель и немного тестовых данных (это можно считать кусочком нашего main.cpp):

#include <string>
#include <vector>

struct Task {
    int id{};
    std::string title;
    bool done{};
    int priority{}; // 1..10
};

std::vector<Task> make_demo_tasks() {
    return {{1, "Read STL", false, 7}, {2, "Submit homework", true, 9}, {3, "Sleep", false, 10}};
}

Дальше мы будем писать небольшие фрагменты кода вокруг этого списка и сравнивать, где алгоритм делает код яснее, а где честный цикл — реально понятнее.

2. Когда алгоритм сильнее: меньше шума, больше смысла

Алгоритмы стандартной библиотеки хороши в ситуациях, когда ваш вопрос к данным легко формулируется одной короткой фразой. Прямо как в жизни: если вопрос «Сколько людей в комнате?» — это одно действие, а если вопрос «Сколько людей в комнате, кто из них в шляпе и почему один держит кактус?» — это уже мини-расследование.

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

«Сколько задач выполнено?» — count_if против ручного счётчика

Здесь типичная ручная реализация выглядит нормально, но в ней уже появляются детали, не связанные со смыслом: переменная-счётчик, if, инкремент. А смысл у нас один: «посчитать выполненные».

Ручной цикл:

#include <iostream>
#include <vector>

int main() {
    auto tasks = make_demo_tasks();

    int done_count = 0;
    for (const auto& t : tasks) {
        if (t.done) ++done_count;
    }
    std::cout << done_count << '\n'; // 1
}

Алгоритм:

#include <algorithm>
#include <iostream>
#include <vector>

bool is_done(const Task& t) { return t.done; }

int main() {
    auto tasks = make_demo_tasks();

    int done_count = std::count_if(tasks.begin(), tasks.end(), is_done);
    std::cout << done_count << '\n'; // 1
}

С точки зрения результата — одинаково. Но по «сигналу смысла» второе часто выигрывает: глазом видно count_if, видно is_done, и мозгу не нужно держать в голове механику счётчика.

«Есть ли хоть одна задача с высоким приоритетом?» — any_of против break

Вторая классика — «найти хоть один подходящий элемент». Ручной цикл почти неизбежно превращается в bool found = false; + break. Это не ошибка, это просто шаблон, который вы вынуждены писать снова и снова.

Ручной цикл:

#include <iostream>
#include <vector>

bool is_high_priority(const Task& t) { return t.priority >= 9; }

int main() {
    auto tasks = make_demo_tasks();

    bool has_high = false;
    for (const auto& t : tasks) {
        if (is_high_priority(t)) { has_high = true; break; }
    }
    std::cout << has_high << '\n'; // 1
}

Алгоритм:

#include <algorithm>
#include <iostream>
#include <vector>

bool is_high_priority(const Task& t) { return t.priority >= 9; }

int main() {
    auto tasks = make_demo_tasks();

    bool has_high = std::any_of(tasks.begin(), tasks.end(), is_high_priority);
    std::cout << has_high << '\n'; // 1
}

Смысл any_of обычно читается быстрее, чем «флаг + break». А ещё any_of уже по контракту умеет остановиться раньше конца диапазона, то есть вы не забудете break (а такое забывают чаще, чем хочется признавать).

«Все ли задачи имеют корректный приоритет?» — all_of как «щит от забытых проверок»

Проверка «все ли элементы удовлетворяют условию» — это ещё один типовой вопрос. Вручную вы пишете флаг ok = true, потом при нарушении ставите false и выходите. В реальных проектах люди иногда забывают выйти, иногда забывают правильную инициализацию, иногда путают true/false (особенно после третьей кружки кофе).

Алгоритм:

#include <algorithm>
#include <iostream>
#include <vector>

bool priority_ok(const Task& t) { return 1 <= t.priority && t.priority <= 10; }

int main() {
    auto tasks = make_demo_tasks();

    bool ok = std::all_of(tasks.begin(), tasks.end(), priority_ok);
    std::cout << ok << '\n'; // 1
}

Здесь читателю не нужно «симулировать выполнение» в голове. Он видит all_of и понимает: «проверка на валидность каждого элемента».

«Найти задачу по id» — алгоритм хорош, но требует дисциплины с результатом

Поиск «где находится элемент» удобно делать через std::find_if. Но важно помнить: результат — это итератор, и его нельзя разыменовывать без проверки. Это место, где алгоритм делает код короче, но требует аккуратности.

#include <algorithm>
#include <iostream>
#include <vector>

bool has_id_2(const Task& t) { return t.id == 2; }

int main() {
    auto tasks = make_demo_tasks();

    auto it = std::find_if(tasks.begin(), tasks.end(), has_id_2);
    if (it != tasks.end()) std::cout << it->title << '\n'; // Submit homework
}

Обратите внимание на маленькую «психологию API»: find_if не возвращает bool, он возвращает позицию. Поэтому после него почти всегда идёт «ритуал безопасности»: if (it != end()).

3. Когда цикл лучше и не нужно стесняться

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

Ручной цикл выигрывает там, где логика не укладывается в одну стандартную формулировку или где побочные действия — это центральная часть задачи. Алгоритмы по философии стандартной библиотеки предпочитают быть «чистыми»: предикат проверяет, компаратор сравнивает, а побочные действия лучше не прятать внутрь.

Один проход, два результата и немного печати

Представим, что мы хотим вывести названия выполненных задач и одновременно посчитать их количество. Да, можно сделать count_if, а потом ещё один цикл для печати. Но если печать — часть сценария, цикл может быть честнее: один проход, всё видно, ничего не «спрятано».

#include <iostream>
#include <vector>

int main() {
    auto tasks = make_demo_tasks();

    int done_count = 0;
    for (const auto& t : tasks) {
        if (!t.done) continue;
        std::cout << t.title << '\n'; // Submit homework
        ++done_count;
    }
    std::cout << "done: " << done_count << '\n'; // done: 1
}

Это тот случай, когда цикл прозрачен: видно, когда печатаем, видно, когда считаем, видно, что всё делается в одном месте и в одном проходе.

Когда нужен индекс и вы не хотите превращать код в ребус

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

#include <iostream>
#include <vector>

int main() {
    auto tasks = make_demo_tasks();

    for (std::size_t i = 0; i < tasks.size(); ++i) {
        std::cout << (i + 1) << ") " << tasks[i].title << '\n';
        // 1) Read STL
    }
}

Этот цикл может быть читабельнее любой «акробатики» с итераторами, потому что индекс — часть смысла вывода. Да, нужно быть внимательным к границам, но зато логика в лоб.

4. Главная ловушка алгоритмов: результат нужно понять правильно

Когда вы пишете цикл, вы обычно сами определяете, что является «результатом»: переменная-счётчик, флаг, найденный индекс. Когда вы используете алгоритм, результат уже задан его контрактом: итератор, bool или число. И вот тут начинаются типичные ошибки новичков: алгоритм выбрали правильно, а результат обработали неправильно.

Классическая дисциплина такая: если алгоритм возвращает итератор, мы сначала проверяем, что он не равен end(). Если алгоритм возвращает bool, мы называем переменную так, чтобы было ясно, что означает true. Если алгоритм возвращает число, мы помним, что это количество, а не позиция.

Антипример: разыменование end() после find_if

Вот код, который иногда «случайно работает», а потом внезапно падает или ведёт себя странно. И хуже всего то, что на маленьких тестах он может выглядеть «нормально».

#include <algorithm>
#include <iostream>
#include <vector>

bool has_id_999(const Task& t) { return t.id == 999; }

int main() {
    auto tasks = make_demo_tasks();

    auto it = std::find_if(tasks.begin(), tasks.end(), has_id_999);
    std::cout << it->title << '\n'; // ОШИБКА: если не нашли, it == end()
}

Правильный вариант — скучный, зато безопасный:

#include <algorithm>
#include <iostream>
#include <vector>

bool has_id_999(const Task& t) { return t.id == 999; }

int main() {
    auto tasks = make_demo_tasks();

    auto it = std::find_if(tasks.begin(), tasks.end(), has_id_999);
    if (it == tasks.end()) std::cout << "not found\n"; // not found
    else std::cout << it->title << '\n';
}

5. Один проход или несколько: критерий без фанатизма

Иногда выбор «алгоритм или цикл» упирается в количество проходов. Например, вам нужно и проверить наличие чего-то, и посчитать количество. Наивное решение алгоритмами — вызвать any_of, потом count_if. Это два прохода. Циклом можно сделать один проход.

С другой стороны, очень часто в учебных задачах и небольших программах разница не критична, а читаемость важнее. Если данные маленькие, а код читается в два раза легче — это хороший обмен. Если данные большие (тысячи/миллионы элементов), и вы делаете много проходов в горячем месте программы, цикл может быть оправдан.

Пример «два результата за один проход» (цикл как честная прозрачность):

#include <iostream>
#include <vector>

int main() {
    auto tasks = make_demo_tasks();

    bool has_done = false;
    int done_count = 0;

    for (const auto& t : tasks) {
        if (!t.done) continue;
        has_done = true;
        ++done_count;
    }

    std::cout << has_done << " " << done_count << '\n'; // 1 1
}

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

6. Мини-схема выбора: алгоритм или цикл

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

Небольшая блок-схема для мозга (да, мозгу тоже нравятся блок-схемы — он просто стесняется):

flowchart TD
    A[Нужно пройти по контейнеру] --> B{Это стандартный вопрос?}
    B -->|Где элемент?| F[find / find_if]
    B -->|Сколько подходит?| C[count / count_if]
    B -->|Есть ли хоть один?| D[any_of]
    B -->|Все ли подходят?| E[all_of]
    B -->|Свернуть в одно значение?| G[accumulate]
    B -->|Нужно упорядочить?| H[sort]
    B -->|Нет, это многошаговый процесс| I[Ручной цикл]

И ещё одна полезная «табличка здравого смысла» (не магия, просто подсказка):

7. Типичные ошибки при выборе между алгоритмом и циклом

Ошибка №1: выбирать алгоритм «на автомате», а не по смыслу вопроса.
Иногда студент видит, что «сегодня день алгоритмов», и пытается любой проход по контейнеру запихнуть в std::count_if или std::find_if, даже если задача на самом деле про печать, форматирование и накопление нескольких значений. В итоге код становится короче, но менее понятным: смысл расползается по нескольким вызовам, и читателю приходится собирать логику по кускам.

Ошибка №2: делать предикат или компаратор с побочными действиями.
Предикат должен отвечать на вопрос true/false, а компаратор — на вопрос «кто раньше». Если внутри предиката вы печатаете в консоль или меняете элементы, код становится непредсказуемым для чтения: алгоритм может вызывать предикат много раз, в разном порядке, и ваш вывод в консоль превращается в шум. Новичкам особенно легко случайно «засунуть логику программы в проверку».

Ошибка №3: разыменовывать итератор результата без проверки.
std::find и std::find_if возвращают end(), если не нашли элемент. Разыменование end() — это уже выход за границу логики программы. Поэтому паттерн «проверить it != end() → использовать *it или it->field» должен стать привычкой уровня «пристегнуться в машине».

Ошибка №4: путать «алгоритм дал ответ» и «алгоритм дал позицию».
any_of возвращает bool, а find_if возвращает итератор. Если вы мысленно ожидаете true/false, но получили позицию, вы начнёте писать странные сравнения или пытаться «превратить итератор в bool» непонятными способами. Лечится просто: перед использованием алгоритма проговорите, что именно он возвращает.

Ошибка №5: пытаться заменить любой цикл двумя-тремя алгоритмами и потерять цельность.
Иногда из благих намерений (сделать «красиво») код разбивают на any_of, потом count_if, потом ещё один цикл на печать. Формально это работает, но для чтения хуже: логика рассредоточена, и становится неясно, что является «основным результатом», а что — вспомогательным. Если смысл задачи — один сценарий, иногда честный цикл делает её цельнее.