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

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++.

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

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

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 в своих ненормальных алгорифмах! Ура...)