Операторы vs компараторы

1. Почему возникает выбор

Когда начинаешь писать operator== и <=>, появляется приятное чувство: «мой тип почти как int». Но довольно быстро жизнь подкидывает реальность: один и тот же объект можно сравнивать по‑разному в разных задачах. В одном месте нам важен id, в другом — «сначала приоритет, потом название», в третьем — вообще «сначала выполненные вниз списка». И вот тут важно не превратить операторы в «швейцарский нож, который ещё и суп варит».

Перегруженные операторы — это умолчания для типа. Если вы добавили a < b, вы как бы говорите: «в большинстве случаев, когда люди видят Task и хотят упорядочить, они ожидают именно такой порядок». А компаратор (чаще лямбда) — это «локальное правило»: прямо сейчас, в этом конкретном std::sort, мы сортируем так, потому что задача такая.

Чтобы не обсуждать это в вакууме, продолжим наше учебное консольное приложение: мини‑трекер задач (условный TODO‑лист), где мы храним задачи в std::vector и умеем их печатать и сортировать.

2. Мини‑модель: TaskId, Priority, Task

Перед тем как спорить «операторы vs компараторы», нам нужен объект, который вообще можно сравнивать. Мы сделаем маленькую модель задачи так, чтобы она была понятной новичку и при этом достаточно «богатой», чтобы возникли разные критерии сортировки и поиска. Важно: модель не обязана быть идеальной — она обязана быть учебной и предсказуемой, чтобы на ней видно было последствия ваших решений.

Начнём с небольшого TaskId (чтобы не путать «число в целом» и «идентификатор задачи») и приоритета:

#include <compare>

class TaskId {
public:
    explicit TaskId(int v) : v_(v) {}

    int value() const { return v_; }

    auto operator<=>(const TaskId&) const = default; // порядок по числу
    bool operator==(const TaskId&) const = default;

private:
    int v_{};
};

enum class Priority {
    Low = 0,
    Normal = 1,
    High = 2
};

Теперь сама задача. Пусть у неё есть id, title, priority, и флаг done. Печать в поток и сравнение мы уже умеем делать по материалу предыдущих лекций.

#include <string>
#include <utility>

struct Task {
    TaskId id;
    std::string title;
    Priority priority{Priority::Normal};
    bool done{false};

    bool operator==(const Task&) const = default;
};

Обратите внимание: здесь operator== = default означает «равны, если равны все поля». Это не всегда правильный смысл равенства, но это очень удобная точка старта для разговора. Через пару разделов мы увидим, когда это становится ошибкой дизайна.

Сделаем ещё вывод в поток, чтобы в примерах сортировки было что печатать:

#include <iostream>

std::ostream& operator<<(std::ostream& os, const Task& t) {
    os << "Task{id=" << t.id.value()
       << ", title=\\"" << t.title << "\\""
       << ", done=" << (t.done ? "true" : "false")
       << "}";
    return os;
}

3. Когда сравнение должно быть частью типа

Когда вы определяете оператор внутри типа (или рядом с ним как свободную функцию), вы не просто добавляете синтаксический сахар. Вы публикуете правило, которое начнут использовать другие части программы: алгоритмы, контейнеры, ваши же будущие функции. Это примерно как назвать поле price и надеяться, что все поймут «цена в долларах», а потом внезапно хранить там «копейки». Формально можно. Счастья мало.

Самый честный критерий: оператор уместен, когда у типа есть естественный, очевидный для большинства читателей смысл сравнения. Для TaskId это легко: два TaskId равны, если число одинаково. Для Task уже не так очевидно: задача может быть «та же самая» по id, даже если title поменяли (переименовали задачу). Или наоборот: у вас может быть система без id, и тогда «равенство по всем полям» — норма.

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

Например, если id — идентичность, то равенство «по всем полям» может быть неправильным. Тогда лучше так:

struct Task {
    TaskId id;
    std::string title;
    Priority priority{Priority::Normal};
    bool done{false};

    bool operator==(const Task& other) const {
        return id == other.id; // идентичность по id
    }
};

Такой operator== делает задачу «той же самой», даже если вы поменяли заголовок или приоритет. И это часто ближе к реальности: задача — это сущность, а поля — её состояние.

4. Порядок по умолчанию: полезно, но опасно

Порядок (<, >, <=>) — ещё более скользкая дорожка, чем равенство. Равенство обычно можно как-то объяснить. А вот порядок часто начинает «притворяться естественным», хотя на самом деле он просто удобный для программиста.

Если вы добавляете <=> для Task, вы определяете дефолтную сортировку. И тут нужно честно спросить: «а есть ли у задачи один естественный порядок, который ожидается везде?». Если у вас есть сильный ответ, например «везде сортируем по id», то можно:

#include <compare>

struct Task {
    TaskId id;
    std::string title;
    Priority priority{Priority::Normal};
    bool done{false};

    auto operator<=>(const Task& other) const {
        return id <=> other.id; // порядок по идентификатору
    }

    bool operator==(const Task& other) const {
        return id == other.id; // и равенство согласовано с порядком
    }
};

Здесь важный момент: мы специально делаем == согласованным с порядком, чтобы не получился «когнитивный диссонанс». Если a == b, обычно ожидается, что a < b и b < a будут ложью.

Но если вы не уверены в «естественном» порядке — лучше не добавлять его внутрь типа. И это не слабость. Это аккуратность. Тип без < не становится хуже как сущность; он просто честно говорит: «порядок зависит от задачи, задавайте его компаратором».

5. Компаратор: сортировка под конкретную задачу

Когда мы сортируем std::vector<Task>, мы почти всегда сортируем для экрана, для отчёта, для выбора пользователем, а не потому что у задач есть философский «естественный порядок». Поэтому std::sort с компаратором — абсолютно нормальная, взрослая практика.

Представим, что в нашем приложении есть команда «показать задачи: сначала невыполненные, потом выполненные; внутри — по приоритету; и только потом — по id». Это не «порядок задачи как сущности», это «порядок представления».

Вот как это выглядит компаратором‑лямбдой:

#include <algorithm>
#include <vector>

int priority_rank(Priority p) {
    return static_cast<int>(p);
}

void sort_for_ui(std::vector<Task>& tasks) {
    std::sort(tasks.begin(), tasks.end(),
              [](const Task& a, const Task& b) {
                  if (a.done != b.done) return a.done < b.done; // false раньше true
                  if (a.priority != b.priority) {
                      return priority_rank(a.priority) > priority_rank(b.priority); // High выше
                  }
                  return a.id < b.id;
              });
}

Заметьте стиль: мы явно проговариваем «если отличаются по этому — решаем по этому, иначе идём дальше». Такой код читается как правила сортировки, а не как загадка. Да, это больше строк, чем = default, зато смысл находится прямо там, где вы его используете.

И теперь главное: вам не пришлось менять смысл Task во всей программе. Вы просто отсортировали для нужного экрана.

6. Поиск: операторы и предикаты

Слово «поиск» часто путают с «упорядочиванием». В учебной голове это обычно одно и то же: «я ищу — значит сравниваю». Но в STL поиск чаще выглядит как «найти элемент, удовлетворяющий условию». Это условие — обычная функция bool(const T&), и чаще всего она пишется как лямбда. Здесь нам не нужен порядок, и часто нам даже не нужен operator==.

Начнём с классического std::find. Он ищет «точно равный элемент». Поэтому ему нужен operator==:

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

int main() {
    std::vector<Task> tasks = {
        {TaskId{1}, "Buy milk", Priority::Normal, false},
        {TaskId{2}, "Fix bug", Priority::High, false}
    };

    auto it = std::find(tasks.begin(), tasks.end(),
                        Task{TaskId{2}, "", Priority::Low, true});

    std::cout << (it != tasks.end() ? it->title : "not found") << '\n';
    // Fix bug
}

Этот пример выглядит странно (мы создали «шаблонную задачу» с пустым названием), но он отлично демонстрирует, что std::find сравнивает через ==. Если ваш == сравнивает только id, то это работает. Если ваш == сравнивает все поля, то поиск «по id» так не сделать — и вам придётся либо создавать точную копию задачи, либо менять подход.

И вот тут на сцену выходит std::find_if: поиск по условию. Ему не нужен operator==, ему нужен предикат.

#include <algorithm>

Task* find_by_id(std::vector<Task>& tasks, TaskId id) {
    auto it = std::find_if(tasks.begin(), tasks.end(),
                           [&](const Task& t) { return t.id == id; });
    return (it == tasks.end()) ? nullptr : &*it;
}

Этот стиль часто лучше даже при наличии ==, потому что условие поиска видно прямо в коде: мы ищем по id, точка. Никаких догадок «а что там в operator== сравнивается?».

7. Полезные нюансы

Шпаргалка: что куда класть

Когда голова кипит, полезно держать перед глазами простую карту решений. Здесь нет «единственно правильного ответа», но есть рабочие эвристики, которые спасают от случайных API‑ошибок и странных операторов.

Обратите внимание: последняя строка — не про операторы напрямую, но она очень практическая. Иногда мы спорим «как сравнивать», когда правильный ответ — «давайте хранить данные так, чтобы не искать перебором».

Компаратор и корректное сравнение

Очень легко написать компаратор, который выглядит правдоподобно, но нарушает ожидания std::sort. В этом курсе мы не будем уходить глубоко в теорию, но базовую интуицию стоит поймать: компаратор должен задавать разумный порядок без противоречий. Если компаратор в одном случае говорит «a меньше b», а потом вдруг при другой проверке начинает вести себя иначе (или зависит от внешнего меняющегося состояния), сортировка может дать странный результат.

Например, плохая идея — компаратор, который использует случайность или глобальный счётчик вызовов. Да, это звучит как шутка, но иногда люди случайно делают почти то же самое, когда захватывают в лямбду ссылку на переменную, которая меняется во время сортировки.

В хороших компараторах есть важная черта: они «чистые». На вход получают два объекта, на выход дают true/false, и это решение зависит только от этих объектов (и, максимум, от константных правил, вроде таблицы приоритетов).

8. Несколько сортировок без ломки модели

Очень типичная ситуация в реальном проекте: пользователю хочется переключатель сортировки. Сегодня «по приоритету», завтра «по названию». И вот здесь особенно важно не пытаться «переписывать operator<=> на лету» (что, к счастью, невозможно) и не делать оператор зависимым от глобальной переменной currentSortMode. Это выглядит как идея, но пахнет как баг.

Сделаем аккуратно: отдельная функция, которая принимает режим и вызывает std::sort с нужным компаратором. Пусть режим пока будет обычным enum class.

#include <algorithm>

enum class SortMode {
    ById,
    ByTitle,
    ByPriority
};

void sort_tasks(std::vector<Task>& tasks, SortMode mode) {
    if (mode == SortMode::ById) {
        std::sort(tasks.begin(), tasks.end(),
                  [](const Task& a, const Task& b) { return a.id < b.id; });
        return;
    }

    if (mode == SortMode::ByTitle) {
        std::sort(tasks.begin(), tasks.end(),
                  [](const Task& a, const Task& b) { return a.title < b.title; });
        return;
    }

    std::sort(tasks.begin(), tasks.end(),
              [](const Task& a, const Task& b) {
                  return static_cast<int>(a.priority) > static_cast<int>(b.priority);
              });
}

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

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

Ошибка №1: пытаться запихнуть все варианты сортировки в operator<=>.
Новички часто думают: «ну я же могу определить порядок, значит сортировка везде будет удобной». А потом оказывается, что «удобный порядок» один, а сценариев сортировки — пять. В результате operator<=> становится либо спорным, либо просто вредным, потому что диктует порядок там, где он не нужен.

Ошибка №2: делать operator== = default, не подумав о смысле идентичности.
= default сравнивает все поля, и это часто неожиданно. Если задача «та же самая» по id, но вы поменяли title, то внезапно a == b станет ложью, и std::find перестанет находить «ту же» задачу. Перед тем как дефолтить ==, проговорите словами: «что значит “равны” для моего типа?».

Ошибка №3: использовать std::find там, где нужен поиск по условию.
Если вам надо найти задачу по подстроке в названии или по статусу done, не мучайте operator== и не создавайте «шаблонный объект для сравнения». std::find_if с лямбдой обычно проще, понятнее и честнее — условие поиска видно прямо в месте вызова.

Ошибка №4: компаратор зависит от внешнего изменяемого состояния.
Сортировка вызывает компаратор много раз и в неочевидном порядке. Если ваш компаратор читает переменную, которая меняется параллельно (или меняется внутри самого компаратора), вы получите «плавающее» сравнение. Итог — странный порядок или, в худшем случае, очень труднообъяснимое поведение.

Ошибка №5: смешивать «равенство» и «похожесть».
Иногда хочется перегрузить operator== так, чтобы задачи считались равными, если у них похожие заголовки или одинаковый приоритет. Но это уже не равенство, а «похожесть». Для «похожести» лучше отдельная функция или предикат в find_if, иначе вы сломаете ожидания от == по всей программе.