🍙 C++ Ranges. Ленивые вычисления (C++20)

Cамое важное свойство адаптеров views: они ленивые (lazy).

Когда ты пишешь data | views::filter(...) | views::transform(...), ты не запускаешь обработку. Ты создаёшь лёгкий view-объект, который хранит ссылку на исходный диапазон и предикаты. Обработка происходит только тогда, когда ты начинаешь итерировать результат — поэлементно, по требованию.

⚠️ Важно: view хранит ссылку на исходный контейнер. Если контейнер изменится или выйдет из области видимости раньше, чем ты начнёшь итерацию — поведение будет неопределённым.

🌸 Пример 1: базовая ленивость

// C++20
#include <vector>
#include <ranges>
#include <iostream>

int main() {
    std::vector<int> v = {1, 2, 3, 4, 5};

    // Создаём view — никакой обработки ещё нет
    auto view = v | std::views::filter([](int x) {
        std::cout << "Проверяем " << x << "\n";
        return x > 2;
    });

    std::cout << "Начинаем итерацию:\n";
    for (int x : view) {
        std::cout << "Результат: " << x << "\n";
    }
}

❗️Вывод — фильтрация и результат чередуются поэлементно. Это и есть ленивость в действии:

Начинаем итерацию:
Проверяем 1
Проверяем 2
Проверяем 3
Результат: 3
Проверяем 4
Результат: 4
Проверяем 5
Результат: 5

Сравни с тем, как выглядел бы «жадный» (eager) подход: сначала все "Проверяем...", потом все "Результат:". Здесь же — один элемент за раз.

🌱 Пример 2: цепочка адаптеров

Можно выстраивать цепочки — каждый адаптер обрабатывает элемент по мере продвижения итератора:

#include <vector>
#include <ranges>
#include <iostream>

int main() {
    std::vector<int> v = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10};

    auto view = v
        | std::views::filter([](int x) { return x % 2 == 0; })  // только чётные
        | std::views::transform([](int x) { return x * x; });   // возводим в квадрат

    for (int x : view) {
        std::cout << x << " ";  // 4 16 36 64 100
    }
}

Здесь transform никогда не видит нечётных чисел — filter не пропускает их дальше. Никаких промежуточных векторов, никаких лишних аллокаций.


🌳 Пример 3: ранняя остановка

Ленивость особенно выгодна, когда тебе не нужны все элементы. views::take берёт ровно столько, сколько нужно, и останавливает обработку:

#include <vector>
#include <ranges>
#include <iostream>

int main() {
    std::vector<int> v = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10};

    // Берём первые 3 чётных числа — и всё, остальные даже не проверяются
    auto view = v
        | std::views::filter([](int x) {
            std::cout << "Проверяем " << x << "\n";
            return x % 2 == 0;
        })
        | std::views::take(3);

    for (int x : view) {
        std::cout << "Берём: " << x << "\n";
    }
}

Вывод:

Проверяем 1
Проверяем 2
Берём: 2
Проверяем 3
Проверяем 4
Берём: 4
Проверяем 5
Проверяем 6
Берём: 6
Проверяем 7 // Могут быть проверены (зависит от компилятора)
Проверяем 8 // хотя это не обязательно

После шестёрки обработка полностью прекращается. Числа 7–10 не тронуты — хотя они есть в векторе.


💡 Итоги

Ленивость — это не просто деталь реализации. Это архитектурное свойство, которое позволяет:

• работать с бесконечными диапазонами (std::views::iota)
• не создавать промежуточные контейнеры при цепочках
• останавливать обработку раньше, как только результат получен

Плата за это — view не кэширует результаты. Если ты итерируешь view дважды, предикаты выполнятся дважды. Если это проблема — преврати результат в вектор через std::ranges::to<std::vector>() (C++23) или просто std::vector(view.begin(), view.end()).


🐸 Продолжение следует...


📍Навигация: Вакансии • Задачи • Собесы

Библиотека C/C++ разработчика

#константная_правильность

🌳 std::call_once и once_flag: явная ленивая инициализация

Иногда нужно инициализировать ресурс ровно один раз, но логика инициализации сложнее, чем в конструкторе. Вот инструмент для этого.

#include <mutex>
#include <memory>

class ResourceManager {
    std::once_flag init_flag_;
    std::unique_ptr<HeavyResource> resource_;

public:
    // once_flag нельзя копировать — явно запрещаем копирование класса
    ResourceManager() = default;
    ResourceManager(const ResourceManager&) = delete;
    ResourceManager& operator=(const ResourceManager&) = delete;

    HeavyResource& get_resource() {
        std::call_once(init_flag_, [this] {
            // Выполнится ровно один раз, даже при гонке потоков.
            // Если инициализация бросит исключение — флаг не выставится,
            // и следующий поток повторит попытку.
            resource_ = std::make_unique<HeavyResource>(load_config());
        });
        return *resource_;
    }
};

// Использование — просто и безопасно
ResourceManager mgr;
auto& r1 = mgr.get_resource(); // инициализирует
auto& r2 = mgr.get_resource(); // возвращает готовый

💡 Когда call_once лучше Meyers Singleton (static local-переменной):

• Инициализация — отдельный этап от конструктора объекта
• Нужно явно контролировать момент инициализации, а не привязывать его к первому обращению к static-переменной
• Логика инициализации требует захвата внешнего состояния (this, параметры)

📊 Оверхед call_once после первого вызова — минимален, но не нулевой: как минимум одна атомарная проверка с барьером памяти. Стоит замерить бенчмарком.

📍Навигация: Вакансии • Задачи • Собесы

Библиотека C/C++ разработчика

#константная_правильность

🚀 Челендж на выходных: полный ленивый pipeline

Собери всё вместе: напиши ленивый pipeline обработки данных без лишних копий и временных контейнеров.

// Дано: файл с числами (по одному на строку)
// Задача: найти сумму квадратов чётных чисел из первых 1000 строк

// Наивное решение (неленивое):
// 1. Загрузить всё в vector<int>          — O(n) память
// 2. Отфильтровать чётные                 — ещё O(n)
// 3. Возвести в квадрат                   — ещё O(n)
// 4. Просуммировать первые 1000           — O(n)

// Ленивое решение должно:
// - Читать файл построчно (не грузить всё)
// - Фильтровать на лету
// - Трансформировать на лету
// - Останавливаться после 1000 элементов

// Скелет:
auto result = lines_from_file("data.txt")       // ленивый итератор строк
    | parse_ints()                              // string -> optional<int>
    | filter_valid()                            // убрать nullopt
    | filter([](int x){ return x % 2 == 0; })  // только чётные
    | transform([](int x){ return x * x; })    // квадрат
    | take(1000)                                // первые 1000
    | sum();                                    // свёртка

// TODO: реализуй каждый адаптер в цепочке

✏️ Задача: реализуй весь pipeline. Можно использовать C++20 Ranges или написать адаптеры вручную. Ключевое требование — в любой момент в памяти хранится не более одного элемента из файла.


📍Навигация: Вакансии • Задачи • Собесы

Библиотека C/C++ разработчика

#междусобойчик

🦾 Надоело чинить «упавших» ИИ-агентов после каждого микросбоя внешних сервисов?

Анонсируем старт продаж большого курса по AgentOps. Мы собрали опыт десятков разработчиков и сделали программу, которая учит выводить ИИ в стабильный прод.

🗓 Ждем вас 28 апреля в 19:00 МСК на эфире: «Как эффективно управлять контекстным окном LLM в мультиагентных системах и не сливать бюджет на токены».

👉 Кто вещает и в чем польза?

Спикер Кирилл Кухарев (Senior AI Engineer в Raft, спикер AI Conf и Highload++). Он реализовал более 50 коммерческих проектов в GenAI и на вебинаре покажет, как взять под контроль работу нескольких агентов, чтобы они не перекидывали друг другу лишний контекст и не сжигали ваши деньги.

В прямом эфире разберем:
• Как формируется контекст в LLM при маршрутизации между агентами;
• Куда утекают лишние токены и возникает перерасход;
• Практические методы: как сжимать историю, грамотно делить задачи, лимитировать передачу контекста и собирать промпты прямо в процессе запроса пользователя.

🔥 Два способа получить максимум:

1. Приходите на вебинар 28 апреля. Дарим участникам промокод на 5.000 ₽ (работает 3 дня после эфира - это шанс забрать курс по самому низу рынка).

2. Выбирайте Инженерный трек. В подарок к нему идет полный доступ к записям и автопроверкам завершенного курса «Разработка ИИ-агентов».

👉 Занять место на вебинаре и стать профи в AgentOps

👁 C++ Ranges. Требования к диапазонам

C++20 ввёл концепты — способ формально выразить требования к типам. В Ranges они используются повсеместно, поэтому важно понимать, что говорят сообщения об ошибках и почему один алгоритм принимает vector, а другой требует что-то большее.

// ❌ Не скомпилируется
std::list<int> lst = {3, 1, 2};
std::ranges::sort(lst);
// Ошибка: list не удовлетворяет концепту random_access_range

// ✅ vector удовлетворяет random_access_range
std::vector<int> vec = {3, 1, 2};
std::ranges::sort(vec);

// ✅ У list есть собственный метод сортировки
lst.sort();

🍋 Иерархия концептов

Концепты выстроены в цепочку наследования: каждый следующий добавляет требования к предыдущему. sized_range и viewable_range — ортогональны иерархии, они не зависят от позиции в цепочке.

range
 └── input_range
      └── forward_range
           └── bidirectional_range
                └── random_access_range
                     └── contiguous_range

‼️ Зачем нужен viewable_range?

Ещё есть viewable_range, он тоже не входит в иерархию. Нужен, так как не любой range можно безопасно обернуть во view. Если передать временный объект, итератор получит висячий указатель — объект уничтожается раньше, чем его успевают использовать. Концепт viewable_range запрещает это на уровне компилятора.


🍩 Проверка концептов в compile-time

Тут всё просто, нужно обернуть проверку в static_assert и сразу, на этапе компиляции, получишь ошибку если что-то не так:

static_assert(std::ranges::random_access_range<std::vector<int>>);
static_assert(!std::ranges::random_access_range<std::list<int>>); 
static_assert(std::ranges::bidirectional_range<std::list<int>>);

🐸 Продолжение следует...

📍Навигация: Вакансии • Задачи • Собесы

Библиотека C/C++ разработчика

#константная_правильность