Сопрограмма, ожидаемая в списке параметров, нарушает другой параметр?

У меня есть следующий код

#include <boost/asio.hpp>
#include <boost/asio/awaitable.hpp>
#include <boost/asio/co_spawn.hpp>
#include <gtest/gtest.h>

template <typename FUNC, typename EXECUTOR> void foo(FUNC, EXECUTOR) {}

struct Marker {
    void const* ptr;
    Marker() : ptr(this) {}
    Marker(Marker const& rhs) = delete;
    ~Marker() { EXPECT_EQ(this, ptr); }
};

boost::asio::awaitable<int> xxx() { co_return 0; }

boost::asio::awaitable<void> test_in_coro() {
    foo([marker = Marker{}]() -> int { return 42; }, co_await xxx());
    co_return;
}

TEST(BugInCoro, Reproduce) {
    boost::asio::io_context ioc;
    boost::asio::co_spawn(ioc, test_in_coro(), boost::asio::detached);
    ioc.run();
}

int main() {
    testing::InitGoogleTest();
    return RUN_ALL_TESTS();
}

Утверждение в деструкторе Marker не выполняется. Более того, я проверил, что ptr такой же, как в конструкторе, а this отличается.

Все работает нормально, если я просыпаюсь перед вызовом foo или сохраняю лямбду в локальной переменной.

Это происходит в gcc 11.x и 12.x, но не в 13.x и не в clang.

Я впадаю в какое-то неопределенное поведение? Или, может быть, это ошибка компилятора?

это один и тот же код, опубликованный дважды?

— 26.07.2024 13:25

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

— 26.07.2024 13:40

Исправлен автономный пример. Интересно, что на моей машине он работает корректно (тот же буст, тот же gcc): imgur.com/FR61Jkg

— 26.07.2024 14:29

c++ boost-asio c++-coroutine

26.07.2024 13:12

Стоит ли изучать PHP в 2023-2024 годах?

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

Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией

В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.

Приемы CSS-макетирования - floats и Flexbox

Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...

Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest

В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...

Концепция локализации и ее применение в приложениях React ⚡️

Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...

Пользовательский скаляр GraphQL

Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...

Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Да, это проблема компилятора. Это было исправлено в GCC13.

Насколько я могу судить, это было исправлено в https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=58a7b1e354530d8dfe7d8fb859c8b8b5a9140f1f

coroutines: Do not promote temporaries that will be elided.

We usually need to 'promote' (i.e. save to the coroutine frame) any temporary
variable that is in a target expression that must persist across an await
expression.  However, if the TE is just used as a direct initializer for
another object it will be elided - and we should not promote it since that
would lead to a DTOR call for something that is never constructed.

Since we now have a mechanism to tell if TEs will be elided, use that.

Although the PRs referenced initially appear to be different issues, they all
stem from this.

Co-Authored-By: Adrian Perl <[email protected]>
Signed-off-by: Iain Sandoe <[email protected]>
PR c++/100611
PR c++/101367
PR c++/101976
PR c++/99576

gcc/cp/ChangeLog:

* coroutines.cc (find_interesting_subtree): Do not promote temporaries
that are only used as direct initializers for some other object.

gcc/testsuite/ChangeLog:

* g++.dg/coroutines/pr100611.C: New test.
* g++.dg/coroutines/pr101367.C: New test.
* g++.dg/coroutines/pr101976.C: New test.
* g++.dg/coroutines/pr99576_1.C: New test.
* g++.dg/coroutines/pr99576_2.C: New test.

Вы можете просмотреть любую из упомянутых ссылок на ошибки для получения дополнительной информации и увидеть, что некоторые из воспроизводителей в основном идентичны вашим, за исключением того, что они не используют типы обещаний Asio.

26.07.2024 22:37

Другие вопросы по теме

Увеличьте отсутствие соответствующей функции-члена для вызова async_wait

Неожиданное предупреждение «указатель равен нулю» в библиотеке boost asio?

Достаточно ли времени жизни локальной лямбды в качестве обработчика завершения для co_spawn, т.е. функции с functor&&?

Странное поведение при передаче кабеля перехватывает `std::initializer_list<std::shared_ptr<Conversation>>` в полный обработчик

Boost Asio: В чем разница между исполнителем, переданным в boost::asio::post, и связанным исполнителем CompletionToken?

Boost Asio: как запустить один обработчик в нескольких независимых цепях?

Какой исполнитель создает co_await boost::asio::this_coro::executor?

Boost Asio: исполнители в сопрограммах C++20

Make_parallel_group: Можно ли использовать его с пулом потоков «post»?

Почему Boost уделяет особое внимание потокобезопасности для отдельных объектов?

Сопрограмма, ожидаемая в списке параметров, нарушает другой параметр?

Ответы 1

Другие вопросы по теме

Похожие вопросы