cppcoro | A library of C++ coroutine abstractions for the coroutines TS | Android library

I figured out a decent solution but I would love to find a better one. I can create a future class that contains an asio::steady_timer. Then I can handle timeouts in a neat way and I can just call cancel the timer when the original coroutine gets a reply. Seems pretty overkill and steady_timer is huge (112 bytes?!) but if it works then it works...

From the documentation of cppcoro::generator, the only "meaningful" operations you can do to a generator is get begin and end iterators via begin() and end(). This is precisely why your second use for (auto n : generatorForNumbers(0, 5)) works. It iterates over the generator. Though you technically hit undefined behavior since there's no stopping condition for the generator so it overflows an int.

You can't print the generator directly. You have to iterate over it. So you could do this instead:

You are breaking a cardinal rule of C++: you wrote a function that takes a potential prvalue and store a pointer that outlives the function call that gave them a prvalue. Indeed, any time you see a function that takes an rvalue-reference (or a const-lvalue-reference) and stores a pointer/reference to that object which will outlive that function, you should consider that code to be highly dubious at best.

If a function takes a parameter as an rvalue reference, that means you're expected to either use it or move from it within that function call. Prvalues are not normally expected to outlive the function call they are passed to, so you either use them or lose them.

In any case, the behavior you're seeing is exactly what you're supposed to see. When a coroutine issues a co_return, it... returns. That means the main body of the coroutine block has exited. return_value is called while the block still exists, but once that is done, the coroutine block and all of its automatic variables (including parameters) go away.

This is why returning references to automatic variables from a normal function is a bad idea. This is just as bad an idea for co_return, even if you're indirectly shepherding that reference to the caller.

The co_yield version works (you still shouldn't do it, because that's not how you're supposed to treat prvalues, but it is required to work) because the co_yield statement itself is told to suspend by the return value of yield_value. This preserves the coroutine's stack, including any prvalues that were within the co_yield statement itself until the coroutine is resumed.

But again, you should do the move in the yield_value function, just as you would for rvalue reference parameters normally.

The problem is, I think, that you declared your return type as task but you don't actually co_return any int.

Does the problem go away if you co_return n?

The operations on the atomic variable itself will not cause data races either way.

std::memory_order_release means that all modified cached data will be committed to shared memory / RAM. Memory order operations generate memory fences so other objects could be properly committed to / read from shared memory.

I did some research and I believe the answer is as follows:

First, there is no lazy<> class in C++. The https://en.cppreference.com/w/cpp/language/coroutines has it wrong. (Refer the draft for confirmation)

So, it's a matter of distinction between the return type of generator and task.

TLDR;

The easiest way to remember is:

generators are associated with co_yield; whereas, tasks are associated with co_await

generator

The co_yield mechanism associated with the generator class is exactly the same as what we would encounter in python (refer the docs) and also much similar to the thread_suspend concept in operating system mechanisms.

You may choose to implement it synchronously or asynchronously. (Refer the cppcoro library for samples.)

A generator type (kind-of) looks like this:

There's a really good article by Raymond Chen, you can find it here.

In your case, you can do something like this.