Форум 'C/C++' на RSDN

Вопрос по непонятому из С++20 короутин

Thu, 18 Jun 2026 13:21:56 GMT

Доброго дня!

В очередной раз пытаюсь разобраться с короутинами из C++20. Среди того, что не понимаю, есть один момент, который можно обозначить как "идеология обращения с асинхронными сущностями". Попробую пояснить о чем речь.

Большинство примеров использования короутин демонстрируют co_await в одну операцию. Что-то вроде:

auto socket = co_await socket_factory::connect(ip);
co_await socket.send(request_packet);
auto reply = co_await socket.receive();
...

Но, насколько я смог понять, в реальности за co_await something() стоит два шага:

1. Вызов something() и получение некого Task-а как результат формирования короутины something (под Task-ом понимается тип возвращаемого something() значения, это может быть и не Task, а какой-нибудь generator или еще что-то, что хранит в себе coroutine_handle из something()).
2. Применение оператора co_await к возвращенному из something() Task-у. С последующей цепочкой вызовов await_ready/await_suspend/await_resume для Awaiter-а (или самого Task-а, если отдельного Awaiter-а нет).

Поэтому, при желании, программист может переписать строчку co_await socket_factory::connect(ip); в более развернутом виде:

// Получили в свое распоряжение короутину connect.
auto connect_task = socket_factory::connect(ip);
... // Тут курим бамбук.
// И только сейчас толкаем ее на выполнение.
auto socket = co_await connect_task;

Теперь к сути вопроса.

Допустим, у меня есть очередь сообщений и я хочу сделать к ней async_receive, который бы представлял из себя короутину. Т.е. что-то вроде:

async_receive_task_t async_receive(message_queue_t queue) {
  ... // Какие-то действия с co_yield/co_return.
}

И чтобы к этому async_receive можно было применять co_await:

auto msg = co_await async_receive(commands_queue);

Сейчас у меня есть мысль, что в async_receive сразу при входе можно делать попытку чтения из очереди. И если очередь не пуста, то немедленно доставать сообщение оттуда.

Т.е. мой async_receive_task_t::promise_type::initial_suspend будет возвращать std::suspend_never, а async_receive будет работать как-то так:

async_receive_task_t async_receive(message_queue_t queue) {
  // Сразу пытаемся взять сообщение если очередь не пуста.
  auto msg = queue.try_get_nonblocking();

  // Если взять не удалось, то будем ждать возвращения в эту короутину
  // из нашего async_receive_task_t::awaiter_t::await_suspend.
  if(!msg) {
    co_yield empty_queue;
    // А когда нам вернут управление, то сделаем еще одну попытку.
    msg = ...;
  }

  co_return msg;
}

Такой "энергичный" подход вроде как хорош тем, что не нужно тратить время если очередь сообщений не пуста. Сразу же внутри async_receive получаем сообщение, наш awaiter_t об этом узнает и вернет true из await_ready. Соответственно, не придется делать попытку приостановить ту короутину, в которой обратились к async_receive.

Однако, меня смущает потенциальная возможность вот какого сценария:

auto receive_coro = async_receive(command_queue); // (1)
// Теперь у нас на руках есть короутина async_receive, но в приостановленном
// состоянии.
...
... // Еще какие-то действия.
...
if(something_went_wrong) return; // Дальше не идем.

// Только сейчас нам нужно сообщение из очереди.
auto msg = co_await receive_coro; // (2)

При "энергичном" подходе если в command_queue было сообщение, то это сообщение будет извлечено в точке (1). Однако, если дело до точки (2) не дойдет, то сообщение будет потеряно.

Что мне кажется неправильным. Ведь co_await-а не было. А значит и явной попытки взять сообщение в обработку не было.

Возможно, правильным был бы "ленивый" подход, в котором promise_type::initial_suspend возвращал бы std::suspend_always. Сама короутина async_receive создавалась бы в приостановленном состоянии, а первая попытка чтения из очереди была бы в awaiter_t::await_suspend. И чтобы awaiter_t::await_suspend возвращал true только если очередь пуста и нужно приостанавливаться до появления в ней сообщений (соответственно, если в awaiter_t::await_suspend сообщение удалось взять, то возвращается false).

Собственно, сам вопрос: правильно ли я понимаю, что с точки зрения C++ных короутин более уместно использовать именно "ленивый" подход для такой гипотетической async_receive?

PS. Про рекомендацию возвращать из promise_type::initial_suspend значение std::suspend_always читал неоднократно. Здесь больше вопрос в том, насколько это уместно с точки зрения нужного мне async_receive.

PPS. Про symmetric transfer тоже читал. Но есть ощущение, что для моего async_receive достаточно будет возврата bool-а из awaiter_t::await_suspend.

Про умные указатели пр. безопасные фишки

Sat, 06 Jun 2026 16:35:29 GMT

Вопрос такой, особенно к @sergey2b и прочим, кто привык к старому C++.

Используете ли вы везде умные указатели или же вам удобнее по старинке и т.н. умные указатели только мешают?

Аналогичный вопрос — про потоки. Используете ли либы с корутинами (какие?) или же по старинке с ручной синхронизацией?

equality_comparable_with

Thu, 04 Jun 2026 12:11:47 GMT

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

И вот это "сравнимы" я попытался записать готовыми концептами std::equality_comparable и std::equality_comparable_with

Дистиллированный пример выглядит так

namespace aha {
    // пусть есть несколько разных структур
    // некоторые из которых сравнимы между собой ad-hoc

    struct foo { bool operator == (const foo&) const = default; };
    struct bar { bool operator == (const bar&) const = default; };
    struct buz { };

    bool operator == (bar const&, foo const&) { return true; }
    bool operator == (foo const&, bar const&) { return true; }

    template<class T> concept Family = std::same_as<T,foo> || std::same_as<T,bar> || std::same_as<T,buz>;

    // и обёртка над типом из этого семейства
    template<Family T> struct wrapper {
        T t;
        bool operator == (wrapper const&) const
            requires std::equality_comparable<T>
            = default;
        template<Family U>
        bool operator == (wrapper<U> const& other) const
            requires std::equality_comparable_with<T, U>
            { return t == other.t; }
    };
}

static_assert(std::equality_comparable<aha::foo>);
static_assert(std::equality_comparable<aha::bar>);

static_assert(std::equality_comparable<aha::wrapper<aha::bar>>);

template<class T, class U> concept ad_hoc_comparable = requires(std::decay_t<T> t, std::decay_t<U> u) { t==u; t!=u; };

static_assert(ad_hoc_comparable<aha::foo, aha::bar>);
static_assert(std::equality_comparable_with<aha::foo, aha::bar>);

И вот оказалось, что фиг вам.
equality_comparable_with зачем-то требует common_reference_t, который в свою очередь требует (специализации) basic_common_reference.

Окей, сделал кастомизацию, как это советуют на cppreference

namespace std {
    template<
        aha::Family T, aha::Family U,
        template<class>class TQ,
        template<class>class UQ
    >
    struct basic_common_reference<T, U, TQ, UQ> {
        using type = void;
    };
}

и всё равно не работает, потому что

static_assert(std::convertible_to<aha::foo, void>);

не может привести const aha::foo& к void.

WTF?! ЧЯДНТ?
Не хотелось бы плодить вспомогательные сущности ad_hoc_comparable, когда есть готовые...

cppreference совсем закрыли ?

Tue, 02 Jun 2026 05:35:49 GMT

Я некоторое время ходил на cppreference.dev
Но сегодня и он недоступен.
А также ru.cppreference.net

Кто-нить еще знает адреса другие ?
Очень уж полезный ресурс.

выделение памяти в constexpr

Sat, 30 May 2026 20:50:30 GMT

Я чего-то не понимаю, почему такие разные ошибки для constexpr std::string и constexpr std::vector.

constexpr std::string sabcd = "abc"; // строка может быть труъ constexpr
static_assert(sabcd == "abc");

constexpr auto sabc = []{
    std::string s;
    s.push_back('a');
    s.push_back('b');
    s.push_back('c');
    return s;
};
static_assert(sabc() == "abc"); // лямбда со строкой наружу - тоже может быть труъ
constexpr auto sabcv = sabc(); // а вот её результат уже не труъ
static_assert(sabcv == "abc"); // ОШИБКА

test.cpp:607:21: error: non-constant condition for static assertion
  607 | static_assert(sabcv == "abc");
      |               ~~~~~~^~~~~~~~
test.cpp:607:21:   in ‘constexpr’ expansion of ‘std::operator==<char, char_traits<char>, allocator<char> >(sabcv, ((const char*)"abc"))’
/usr/include/c++/13/bits/basic_string.h:3730:24:   in ‘constexpr’ expansion of ‘(& __lhs)->std::__cxx11::basic_string<char>::size()’
test.cpp:607:21: error: the value of ‘sabcv’ is not usable in a constant expression
test.cpp:606:16: note: ‘sabcv’ used in its own initializer
  606 | constexpr auto sabcv = sabc();
      |                ^~~~~

constexpr auto vabc = []{
    std::vector<char> v;
    v.push_back('a');
    v.push_back('b');
    v.push_back('c');
    return v;
};
static_assert(vabc().size() == 3); // лямбда с вектором - труъ

constexpr auto vabcv = vabc(); // а тут прямо сразу ОШИБКА

/usr/include/c++/13/bits/allocator.h:195:52: error: ‘<lambda()>()’ is not a constant expression because it refers to a result of ‘operator new’
  195 |             return static_cast<_Tp*>(::operator new(__n));
      |                                      ~~~~~~~~~~~~~~^~~~~

Композиции, третий подход к снаряду!

Thu, 28 May 2026 01:44:31 GMT

Когда я внедрил идею с резолвером к себе в ненормальное, то столкнулся с неприятным явлением.
В ненормальном у меня есть списки альтернатив порядка 100 штук, и опрашиваются они порядка 500 раз.
Это приводит к тому, что получается шлемюэлева туча типов

class resolver<A1, typelist<>, F1, ..., F100> : public
class resolver<A1, typelist<F1>, F2, ..., F100> : public
.....
resolver<A1, typelist<F1,...,F50>, F51, F52,..., F100> // допустим, F51 подошла
{
A2 operator()(A1 a, F1,...,F50, F51 f, F52,...,F100) const { return f(a); }
};

class resolver<A2, typelist<>, F1, ..., F100> : // и так далее
.....
class resolver<A500, typelist<>, F1, ..., F100> : // и так далее

Для каждого типа аргумента у нас этажерка из O(Nfuns) пустых, слава богу, структур — но у каждой из них O(Nfuns) параметров!

Компиляция улетает в небеса. (При том, что я переписал резолвер под конкретику ненормального).

Поэтому я вернулся обратно к старым добрым fold expressions.

В обобщённом коде это выглядит так.

// концепт, проверяющий критерий
template<class T, CRITERIA C>
concept fits_criteria = C<T>::value;

template<class F, CRITERIA C, class A>
concept appropriate_alternative = Callable<F> && fits_criteria<std::invoke_result_t<F, A>, C>;
// 1) можно вызвать
// 2) и результат подходит под критерий остановки


// успешный результат поиска функции - это обёртка-ссылка на эту функцию
template<Callable F> struct solution {
    static constexpr bool value = true;
    F f; // ссылка

    // отбрасываем хвост свёртки
    constexpr auto operator || (auto&& g) const { return *this; }

    // вызов аргумента (который априори уже подошёл)
    constexpr decltype(auto) operator()(auto&& a) const {
        return FFWD(f, a);
    }
};

// затравка поиска подходящей функции
// (такой, что C< decltype(f(a)) >)
template<CRITERIA C, class A> struct seed {
    static constexpr bool value = false;

    constexpr auto operator || (auto&& f) const {
        using F = decltype(f);
        if constexpr (appropriate_alternative<F, C, A>)
            return solution<F>{FWD(f)};
        else
            return *this;
    }
};

template<CRITERIA C> struct run_alternatives {
    constexpr auto get_alternative(auto&& a, Callable auto&&... fs) const {
        return ( seed<C, decltype(a)>{} || ... || FWD(fs) );
    }
    constexpr decltype(auto) operator()(auto&& a, Callable auto&&... fs) const
    RETURN_IF_RESOLVED(
        get_alternative(FWD(a), FWD(fs)...) (FWD(a))
    )
};

Тут у нас для каждого аргумента 1 seed, 1 solution и O(Nfuns) операторов ||
— <C,A,F>(seed<C,A>, F) — для всех F, которые ещё не подошли
— <F,G>(solution<F>, G) — где F,G — пара смежных функций, а не все со всеми

Компилятору это кажется гораздо меньшей проблемой.
Опять же, операторы смежных пар инстанцируются ровно один раз.

Композиции, reloaded

Mon, 25 May 2026 15:55:40 GMT

Ветка "как посокращать конструкторы" шибко выросла
https://rsdn.ru/forum/cpp/9091851.flat#9091851

Поэтому хочу предложить вот такое резюме.

Как совсем-совсем идеально передавать аргументы и возвращать результаты двух видов композиций
— список альтернатив (выполнить первую подходящую по совместимости аргумента и критерию результата)
— цепочка (выполнить до отсечки по несовместимости аргумента или критерию результата)

Творчески переработал идеи, выдвинутые товарищем rg45
и сделал такой код.
Он длинный, поэтому см. гитхаб.
Хедер https://github.com/nickolaym/cpp-fun/blob/main/single-files/compose.h
и юниттесты https://github.com/nickolaym/cpp-fun/blob/main/single-files/compose.cpp

Альтернативы ассоциативны,
то есть, допустим, у нас есть функции f, g, h, i, j, k,
и f и g не подошли, а h подошла (и по аргументу, и по результату),
в этом случае мы с любого уровня вложенности вернём h(x) и не станем рассматривать альтернативы позади неё.

seq(f, g,     h, i, j,  k )(x) = h(x)
seq(f, g, seq(h, i, j,  k))(x) = h(x)
seq(f, g, seq(h, i, j), k )(x) = h(x)

Цепочка по-прежнему не обладает свойством ассоциативности,
то есть, допустим, у нас есть функции f, g, h, i, j, k
и мы прерываемся на h из-за того, что тип, возвращаемый из h, не влезает в i.
в этом случае мы вылезем на внешний уровень, а там окажется следующий шаг k, в который может влезть результат.

seq(f, g,     h, i, j,  k )(x) =   h(g(f(x)))
seq(f, g, seq(h, i, j,  k))(x) =   h(g(f(x)))
seq(f, g, seq(h, i, j), k )(x) = k(h(g(f(x))))

Но если ограничить предметную область условием, что критерий "не влезает в следующую функцию" совпадает с предметным "это искомый результат"
(безотносительно того, какую роль в этом играет явный критерий остановки — параметр шаблона),
то ассоциативность выполнится.
То есть, если h(g(f(x))) не влезло в i, то оно не должно влезть и в k.
Либо же, если оно не влезло, то оно же подпало под критерий остановки, — в таком случае оно и этажом выше подпадёт под критерий остановки.

(Договорившись об этом, я вполне могу делать циклы for и while в своих ненормальных алгорифмах! Ура...)

как посокращать конструкторы?

Fri, 22 May 2026 17:02:00 GMT

Продолжаю пилить свои ненормальные алгорифмы https://github.com/nickolaym/nenormal
и захотел минимизировать количество move-конструкторов рантаймовых типов.

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

Если упрощать, то это выглядит вот так

template<class T, class A> struct augmented_text {
  T text; // чистый компайл-тайм
  A aux; // потенциально рантайм
};
template<class X> concept AugmentedText = ..... remove_cvref_t<X> = augmented_text<T,A> .....;

AugmentedText auto long_recursive_operation(AugmentedText auto&& arg) {
  .....
  return yet_another_long_recursion_operation(
    augmented_text{
      .text = new_text,
      .aux = arg.aux(.....), // вычисляет своё следующее значение
    }
  )
  .....
};

Одна из обёрток — это функция с внешним аккумулятором

template<class F, class A>
struct cumulative_effect {
  F f;
  A a;
  cumulative_effect operator()() const { return cumulative_effect{f, f(a)}; }
  // дополнительные аргументы сейчас не буду подвёрстывать, чтоб не захламлять
  // равно как и изменчивость типа A
};

И вот тут у меня начались проблемки.
Для начала, нужно сделать две версии оператора() — const& и &&.

  cumulative_effect operator()() && {
    A a1 = f(std::move(a)); // сперва вычислили новый аккумулятор
    return cumulative_effect{
      std::move(f), // затем в конструкторе F(F&&) перенесли содержимое f (инвалидировали this->f)
      std::move(a1) // и в конструкторе A(A&&) перенесли содержимое a1
    };
  }

Если просто написать

  return cumulative_effect{std::move(f), f /* инвалидированное */ (std::move(a)) };

получим неопределённое поведение.

Ок. Можно сделать промежуточную функцию

  cumulative_effect rewrite(A&& a1) && { return cumulative_effect{std::move(f), std::move(a)}; }
  cumulative_effect operator()() && { return rewrite(f(std::move(a))); }

но это — размен шила на мыло.

Можно пойти чуть дальше — отложить вызов в конструктор

  cumulative_effect(do_it_tag, cumulative_effect&& old)
    : f(std::move(old.f))
    , a(this->f(std::move(old.a))
  {}
  cumulative_effect operator()() && { return cumulative_effect(do_it_tag{}, std::move(*this));  }

Но добавление конструктора уничтожает возможность агрегатной инициализации.
Это значит, что будет ещё и конструктор

  cumulative_effect(F&& f, A&& a)
    : f(std::move(f))
    , a(std::move(a))
  {}

и значит, в точке создания стартового значения мы получим +1 перемещение функции и +1 перемещение аккумулятора.

Как эту проблему я сейчас решил (ещё не закоммитил).

Просто поменял местами поля в структуре.

template<class A, class F> struct cumulative_effect {
  A a;
  F f;
  // инициализация - агрегатная, 0 промежуточных конструкторов

  cumulative_effect operator()()&& {
    return cumulative_effect{
      f(std::move(a)), // передача a по ссылке, и пусть там f делает что хочет
      std::move(f), // F(F&&)
    };
  }
};

Из оператора, естественно, происходит copy elision, поэтому поля создаются в клиентском объекте.
Итого ровно 1 перемещение f и 0 перемещений нового аккумулятора.

Но это потребовало поставить телегу впереди лошади.
Некрасивенько... Хотя, если так подумать, у меня там весь код в конвеерном стиле arg >> handler >> handler ....

Но может быть, есть и другие способы? Какое-нибудь колдунство C++23, о котором я не подозреваю?

Проверить все поля структуры

Sun, 17 May 2026 15:19:54 GMT

Есть ли в современном C++ способ сделать что-то со всеми полями произвольной структуры (предполагается, что они одного типа), например, проверить на равенство 0?

ненормальные нормальные алгорифмы

Fri, 01 May 2026 20:23:33 GMT

Вот давеча LaptevVV спрашивал про constexpr, так у меня есть кое-чего.
Хочу показать свою заготовку.
Пилю библиотеку Нормальных Алгорифмов Маркова во время компиляции.
https://github.com/nickolaym/nenormal

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

Из TODO
— обмазать всё пространствами имён
— унифицировать имена и даже их стиль (там у меня и кемелКейс местами есть)
— переписать доки, нормально осмыслить базис теории категорий, который там просвечивает, но вполсилы
— сделать так, чтобы код одинаково хорошо работал и во время компиляции на уникальных типах, и во время исполнения на однородных
— сделать аугментацию более универсальной (сейчас сигнатура колбеков зафиксирована, и вызываются они строго в определённых местах)
— выкинуть неудачные подходы к снаряду, добавить удачные
— сделать инструменты статического и динамического анализа машины (возможное зацикливание, ошибки, отчёты...)

Пока всего этого нет, — статьи тоже нет )))
Но я обещаю, будет!

Что это и зачем

1) НАМ — абстрактная машина, представляющая последовательность правил поиска-и-замены подстрок. Состояние машины — это строка.
Машина ищет первое подходящее правило и меняет первое вхождение искомой строки на заменную. Если правило не помечено, как финальное, то машина повторяет эту процедуру.
Если ничего не подошло, то состояние не изменилось и, очевидно, не изменится. Такое диагностируемое зацикливание также является финальным состоянием.
Можно сказать, что в конце НАМ-программы неявно стоит правило (""/"",стоп).

2) Во время компиляции использовать динамические контейнеры можно ОЧЕНЬ ограниченно, поэтому сделал всё на чистых константах времени компиляции, для этого нужны зависимые типы.

3) Циклы на полиморфных типах невозможны, поэтому сделано всё на рекурсии. Но рекурсия — ограниченный ресурс компилятора (да и рантайма), поэтому применил лайфхаки по развёртыванию циклов.

Сейчас машина допускает программы неограниченной длины (300 правил как нефиг делать), работающие не более 9000 итераций (глубина 900 помножить на развёртывание цикла на 10 шагов).
Увеличить время работы можно экспоненциально!!! (сделать цикл саморасширяемым), но это в конечном счёте убьёт компилятор.

Пример программы

constexpr auto executor = machine_fun<
  rule_loop<
    rules<
      rule<str{"hello"}, str{"privet"}, regular_state>{},
      rule<str{"world"}, str{"mir"}, regular_state>{}
    >{}
  >{}
>{};
// правила внесены как аргументы шаблона, а не как члены кортежа. всё равно типы зависимые, поэтому члены-данные - избыточны

constexpr auto input_value = str{"hello world!"}; // строка времени компиляции - здесь это константный массив (длина выведена из литерала)
constexpr auto input = ct<input_value>{};         // константа времени компиляции с уникальным типом

constexpr auto result = executor(input); // в constexpr-функцию (operator()) передали истинную константу и получили на выходе истинную константу
constexpr auto result_value = result.value; // сама строка лежит в статической константе

static_assert(result_value == str{"privet mir!"});

В порядке безумия я там даже умножение и деление на марковских алгорифмах забабахал. Последовательность Коллаца.
Работает! Только компилируется около полутора минут.