I think the slide with resumable_thing& operator=(resumable_thing&& other) (19:06) has a bug. Correct code should also check whether this->_coroutine and other._coroutine are different, and, if they are, destroy the old this->_coroutine before assigning the handle. Otherwise the code like this would leak memory and other resources: resumable_thing first_counter = counter(); resumable_thing second_counter = counter(); first_counter = std::move(second_counter); // leak of the original first_counter coroutine
Though, to be honest, this is quite a contrived example. Yet the proposed operator= from the slide is not fully correct. I'd prefer to =delete it instead of implementing. Having a move constructor without operator= should be enough for almost all normal use cases.
That would break any code that uses _await_ or _yield_ as an identifier. It would also be less obvious that the routine is a coroutine rather than the garden-variety kind.
Yes, he did. He should have called that function something else, like my_resume(), to make it clear that you're not calling the coroutine_handle's resume() function directly.
Am I crazy in thinking this could replace classes? If not in C++, in some other llvm-based language? One could merge the constructor body and the class definition. Think about it: they're converting function local/"stack" variables into struct fields. Why not have "classes" that are entirely coroutine ctors? Static members remain function static vars. Nest the coroutines inside a namespace for appropriate lexical scoping. At that point, you come awful close to unifying classes/structs, namespaces, and blocks. Beside the crazy idea above, coroutines could make passing "lazy" parameters simple--a parameter where the function body gets to decide if and when to evaluate an argument, rather than eagerly evaluating all parameters before entering the body. This enables writing functions with short-circuiting, like `if...then`. rather than clunky approaches like passing a callable object and a list of args or a struct, or using mind-numbingly verbose patterns like visitor. Imagine what you could do in `std::for_each` situations if you could do all this on fly with very low ceremony. I actually think cheap coroutines are going to be bigger than anyone gives credit, especially if built into the innards of llvm and gcc, and able to do heap elision like discussed.
It's common in Javascript. Everything in the local function scopre is private, and then a associative array of functions is returned to become the public interface.
This article gives some good explanations: meetingcpp.com/index.php/br/items/resumable-functions-async-and-await.html Yes, there is a hype for coroutines, we will see if they live up to it. The standard committee is not known for hasty changes to the C++ language, so no need to worry.
I've implemented at least two Open Source frameworks that attempt to make asynchronous code easier to write. Both are possibly more confusing than callbacks. But callbacks are really awful as they force you to break up an ordinary control flow in some very unintuitive ways that make your code a lot harder to read and understand. And threads are too much overhead both in OS resources and in terms of how much synchronization code you're suddenly forced to add to your code. And that synchronization code oftentimes has a significant performance cost as well. So, co-routines are a really great idea, and they're long, long overdue.
Co-Routine should be programmed by c/c++ as skill programmer; like this every think in library and we ‘should follow you’ instead to looking for best solutions for every program, algorithm, software… Over-Library-Zation will kill c/c++.
Learned VB and C# and had a lot of fun. Opened a CPP file to try and edit it and I can't make it even print my bloody name, so YT classes please save me.
the good news is in en.cppreference.com/w/cpp/language/main_function the unused argc and argv is not needed and return 0 can be implied. #include int main() { std::cout
The year is 2024, and this is still one of the clearest talks about coroutines so far!
The year is 2022, and this is still one of the clearest talks about coroutines so far!
The year is 2023, and this is the best co-routines talk I've seen so far. I will update this comment if I find something else
The year is 2021, and this is still one of the clearest talks about coroutines so far!
can u please suggest some other good ones please...
It's not clear to me what's it referring when he said "suspend", what's actually being suspended here?
Not sure why this talk isn't more popular. As other folks mentioned, this really is the best description of coroutines.
One of the best talks on cpp co routine.
Excellent talk 👏
Can someone provide a link to the talk "later this afternoon"? 38:03
Maybe a little late, but for future watchers: ua-cam.com/video/v0SjumbIips/v-deo.html
4:18 _state->conn_ is not declared anywhere.
At 4:00, is do_while function a recursive function?
8:00 I thought this was a trick question and this was a variable declaration 🤣
This talk look alike to CppCon 2015: Gor Nishanov “C++ Coroutines - a negative overhead abstraction"
I think the slide with resumable_thing& operator=(resumable_thing&& other) (19:06) has a bug. Correct code should also check whether this->_coroutine and other._coroutine are different, and, if they are, destroy the old this->_coroutine before assigning the handle. Otherwise the code like this would leak memory and other resources:
resumable_thing first_counter = counter();
resumable_thing second_counter = counter();
first_counter = std::move(second_counter); // leak of the original first_counter coroutine
Though, to be honest, this is quite a contrived example. Yet the proposed operator= from the slide is not fully correct.
I'd prefer to =delete it instead of implementing. Having a move constructor without operator= should be enough for almost all normal use cases.
Why in the “let‘s look at future…” co_await after override that returns an awaiter can still be assigned to int?
Instead of co_await and co_return, why not "await' and 'yield'?
That would break any code that uses _await_ or _yield_ as an identifier. It would also be less obvious that the routine is a coroutine rather than the garden-variety kind.
Dont yield() the world man.
Instead of co_await why not co_await_and_while_waiting_hit_a_noob
In his slides did he miss defining the method resumable_thing::resume() which should call the coroutine_handle::resume()?
Yes, he did. He should have called that function something else, like my_resume(), to make it clear that you're not calling the coroutine_handle's resume() function directly.
Is a corouting same as Python functions using yield keyword ?
Yes, one application of them is Python-style generators.
Am I crazy in thinking this could replace classes? If not in C++, in some other llvm-based language? One could merge the constructor body and the class definition. Think about it: they're converting function local/"stack" variables into struct fields. Why not have "classes" that are entirely coroutine ctors? Static members remain function static vars. Nest the coroutines inside a namespace for appropriate lexical scoping. At that point, you come awful close to unifying classes/structs, namespaces, and blocks.
Beside the crazy idea above, coroutines could make passing "lazy" parameters simple--a parameter where the function body gets to decide if and when to evaluate an argument, rather than eagerly evaluating all parameters before entering the body. This enables writing functions with short-circuiting, like `if...then`. rather than clunky approaches like passing a callable object and a list of args or a struct, or using mind-numbingly verbose patterns like visitor.
Imagine what you could do in `std::for_each` situations if you could do all this on fly with very low ceremony. I actually think cheap coroutines are going to be bigger than anyone gives credit, especially if built into the innards of llvm and gcc, and able to do heap elision like discussed.
It's common in Javascript. Everything in the local function scopre is private, and then a associative array of functions is returned to become the public interface.
Not that crazy, closures and objects are really more or less the same thing
This resumable_thing is awfully similar to std::future. Why the duplication?
This article gives some good explanations:
meetingcpp.com/index.php/br/items/resumable-functions-async-and-await.html
Yes, there is a hype for coroutines, we will see if they live up to it. The standard committee is not known for hasty changes to the C++ language, so no need to worry.
I can't help but feel these will not live up to the hype
I've implemented at least two Open Source frameworks that attempt to make asynchronous code easier to write. Both are possibly more confusing than callbacks. But callbacks are really awful as they force you to break up an ordinary control flow in some very unintuitive ways that make your code a lot harder to read and understand.
And threads are too much overhead both in OS resources and in terms of how much synchronization code you're suddenly forced to add to your code. And that synchronization code oftentimes has a significant performance cost as well.
So, co-routines are a really great idea, and they're long, long overdue.
Co-Routine should be programmed by c/c++ as skill programmer; like this every think in library and we ‘should follow you’ instead to looking for best solutions for every program, algorithm, software…
Over-Library-Zation will kill c/c++.
Well that's disgusting. I feel like it would be better to not have coroutines yet than to have this.
Learned VB and C# and had a lot of fun. Opened a CPP file to try and edit it and I can't make it even print my bloody name, so YT classes please save me.
#include
int main(int argc, char *argv[])
{
std::cout "Guilherme Moresco"
the good news is in en.cppreference.com/w/cpp/language/main_function the unused argc and argv is not needed and return 0 can be implied.
#include
int main() {
std::cout