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

Корутины C++: как приручить асинхронный I/O

Tue, 22 Sep 2026 17:41:21 GMT

Всем привет!

Анонс статьи не в "прикладном С++", а тут, потому что идёт разбор языковых тонкостей:
https://habr.com/ru/articles/1085348/

Как MSVC теряет деструкторы в корутинах

Sun, 20 Sep 2026 21:29:13 GMT

Всем привет, накопал неприятный баг компилятора.

Корутина не вызывает деструкторы локальных (для её фреймов) объектов в релизе:

#include <coroutine>
#include <cstdio>

bool destroyed = false;

struct trace { ~trace() { destroyed = true; } };

struct fire_and_forget {
    struct promise_type {
        fire_and_forget get_return_object() const noexcept { return {}; }
        std::suspend_never initial_suspend() const noexcept { return {}; }
        std::suspend_never final_suspend() const noexcept { return {}; }
        void return_void() const noexcept {}
        void unhandled_exception() const noexcept {}
    };
};

struct capture {                       // отдаёт наружу свою же ручку
    std::coroutine_handle<>* out;
    bool await_ready() const noexcept { return false; }
    void await_suspend(std::coroutine_handle<> h) const noexcept { *out = h; }
    void await_resume() const noexcept {}
};

fire_and_forget coro(std::coroutine_handle<>& out) {
    trace held;
    co_await capture{&out};
}

int main() {
    std::coroutine_handle<> waiter;

    coro(waiter);
    waiter.resume();                   // тело доходит до конца

    std::printf("%s\n", destroyed ? "ok" : "BUG: ~trace() was not called");
    return destroyed ? 0 : 1;
}

cl /std:c++20 /EHsc /Od repro.cpp   ->  ok
cl /std:c++20 /EHsc /O2 repro.cpp   ->  BUG: ~trace() was not called

Матрица:
/Od — чисто,
/O1, /O2, /Ox — сломано;
/O2 /Ob0 — снова чисто,
/Ob1, /Ob2, /Ob3 — сломано.

Значит, дело во встраивании фрейма.

x86 — ОК на всех уровнях.
Болеет только x64;

Уровень языка ни при чём: C++17 через /await:strict, C++20, /std:c++23preview, /std:c++latest — одинаково.
/GL, /MT, /MD, /GS-, /permissive-, /Gy, /Gw, /guard:cf, /Qspectre, /arch:AVX2, /Zi, /GR- — ничего не меняют.

А вот это забавно:

ключ	результат
/EHs, /EHsc	деструктор пропущен, кадр не освобождён
/EHa, /EHac	всё правильно

Т.е. для случая обслуживания аппаратных (асинхронных) исключений код генерируется верный. ))

Документация /EH объясняет, чем модели отличаются внутри: «When you use /EHs or /EHsc, the compiler assumes that exceptions can only occur at a throw statement or at a function call. This assumption allows the compiler to eliminate code for tracking the lifetime of many unwindable objects».

Проверяем в лоб: берём шесть вариантов одного и того же тела, отличающихся только тем, обязан ли компилятор считать, что тут может возникнуть исключение. /std:c++latest /EHsc /O2:

тело корутины	результат
ничего бросить не может (всё noexcept)	деструктор пропущен
недостижимый throw: if (never) throw …, где never — volatile bool = false	деструктор выполнен
вызов функции из другой единицы трансляции	деструктор выполнен
co_await внутри try { } catch (...) { }	деструктор выполнен
awaiter без noexcept	деструктор выполнен
промис без noexcept	деструктор выполнен

То есть: компилятор, решив, что тело корутины не бросает, выбрасывает учёт времени жизни — и вместе с ним уходит обычная уборка, к исключениям никакого отношения не имеющая: деструктор локального объекта и вызов функции освобождения кадра.

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

Форма с владельцем (final_suspend() возвращает suspend_always, кадр сносит тот, кто его держит) не задета — там всё пашет как ожидалось. У меня изначально был только этот вариант корутины, который обслуживался фреймворком, всё было ОК.

Добавил второй тип корутины, которую "выстрелил и забыл" — и натрахался половину суток в стиле "то ли лыжи не едут, то ли я ..."
(выходной день насмарку)

=============
Отправил баг в MS по стандартному каналу фидбэка студии, но почему-то не вижу его.
А кто-то отправлял баги в MS, там сразу он виден или только когда заводится feedback по нему?
На всякий случай отправил в STL-тим, там поживее реагируют:
https://github.com/microsoft/STL/issues/6458

Выбор операторов для переопределения

Fri, 18 Sep 2026 18:50:44 GMT

Всем привет!

Вопрос на чувство вкуса, читабельность и случайные грабли.

Есть двусторонний биндинг контрола к observable-полю модели:

    TextBox {
        text = Bind {eq.x1},
    },

https://github.com/dmitry-valyukov/wxl/blob/main/samples/Quadratic/main.cpp

Как только захотелось прикрутить односторонний биндинг, так стало видно, что возникает путаница:

    TextBox {
        text = BindRead {eq.x1},
    },

    TextBox {
        text = BindWrite {eq.x1},
    },

В реактивном подходе никогда не понятно, кто кого read/write, потому что два участника.
Наверно надо выкидывать тег-тип полностью, потому что только путаницу создаёт.

Есть идея перейти на переопределения операторов, чтобы было видно, кто кого.

    TextBox {
        text = eq.x1,  // Двусторонний биндинг 
    },

Что плохо — что к синтаксическому хелперу через operator= много чего подвязывается, могут начаться гонки по приведениям типов.
Да и теряется на фоне остальных присвоений свойств, а биндинг должен "ловиться" глазами, потому что ради него рисуют формочки обычно.

    TextBox {
        text >= eq.a,  // Односторонний биндинг 
    },
    TextBox {
        text <= eq.x1, // Односторонний биндинг 
    },

Что плохо — левая стрелка нормальная, правая — оперение от стрелки.

Пока мест склоняюсь к такому:

    TextBox {
        text <=> eq.a, // Двусторонний биндинг 
    },
    TextBox {
        text >> eq.b,  // Односторонний биндинг 
    },
    TextBox {
        text << eq.x1, // Односторонний биндинг 
    },

Не выглядит ли это птичьим языком и вообще дичью?
Кто-то развлекался достаточно в реактивных фреймворках?
И какие косяки могут быть?

Про операторы << и >> косяки понятные...
Проще было бы с <= и >=, но несимметричность стрелок огорчает внутреннего перфекциониста, отсюда желание обсудить. ))

задачка на знание стандарта

Fri, 18 Sep 2026 09:32:25 GMT

Что в коде не так?

auto fetch() { // просто для примера. Здесь всё нормально
  return std::vector<std::string> {"1", "2", "3"};
}

template<typename Proj = std::identity>
auto fetchData(Proj proj = {}) {
  std::vector<std::string> data = fetch();
  data = proj(std::move(data));
  return data;
}

Можно даже с нейронками попытаться ответить (потому как клод собственно эту ошибку и допустил)

Ответ

An object of a type defined in the C++ standard library may be move-assigned (11.4.6 [class.copy.assign]) to itself. Such an assignment places the object in a valid but unspecified state unless otherwise specified.

Так что такой код приводит к unspecified behaviour

fetchData();

Поведение зависит от либы. gcc/clang удалил данные.

именна параметров функций и методов

Fri, 28 Aug 2026 11:26:17 GMT

У нас на работе большая code base без какой либо документации
мой вышестояший коллега в библиотеке которую я сопровождаю по собственной иницативе удалил все имена параметров в декларации С++ классов

class VideoProcessor {
public:
    void ProcessFrame(const Frame& frame,
                      uint32_t timeout_ms,
                      bool blocking);
};

class VideoProcessor {
public:
    void ProcessFrame(const Frame&,
                      uint32_t,
                      bool);
};

скажите пожалуйста это нормальная практика ?
если нет как можно аргументировать что это излишни

usnig this_type = ???;

Mon, 20 Jul 2026 14:07:52 GMT

В продолжение темы: Получить тип класса

В рамках С++20 (и выше, на будущее)
Есть ли возможность получить тип класса, находясь внутри класса и не используя имя класса?

[сcode]
class A
{
using this_type = ???; // что угодно, но имя класса (в данном случае A) встречаться не должно
};
[/сcode]

news: cmake + import std + MSVC - works

Sat, 11 Jul 2026 16:51:39 GMT

и так благодаря мне
мой патч решили включить в cmake
теперь import std; под windows
работает для cmake + (clang или clang-cl) + MSVC stl

жаль, но патч не вошел в вышедший на днях cmake 4.4.0 (кстати cmake + clang-cl уже поддерживает модули в cmake 4.4.0)
но точно будет в следующем cmake 4.5.0 релиз запланирован где то на октябрь
и возможно войдет в патч фикс cmake 4.4.1 дата выхода не известна

UB из-за оператора defined в макроопределениях

Fri, 10 Jul 2026 09:14:09 GMT

С большим удивлением узнал, что еще в C99 (6.10.1-3) и C++11 (16.1-4) использование оператора defined в макроопределении объявлено UB. Как нужно реализовать препроцессор (хоть внешний, хоть встроенный в компилятор), чтоб его поведение на таких макросах было менее определенным, чем на макросах, переопределяемых через #undef?

Вопрос по непонятому из С++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++.

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

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