CppCon 2016: James McNellis “Introduction to C++ Coroutines"
Vložit
- čas přidán 31. 05. 2024
- CppCon.org
-
Presentation Slides, PDFs, Source Code and other presenter materials are available at: github.com/cppcon/cppcon2016
-
One of the most interesting new features being proposed for C++ standardization is coroutines, formerly known as “resumable functions”. C++ coroutines are designed to be highly scalable, highly efficient (no overhead), and highly extensible, while still interacting seamlessly with the rest of the C++ language.
This session will consist of an in-depth introduction to C++ coroutines. We will begin by looking at the rationale for adding coroutines to the C++ language. We will then demonstrate and explain a sequence of coroutines that gradually introduce the features of C++ coroutines. This part of the talk will show both how to write various forms of coroutines and also how the coroutines extensibility model enables existing libraries to be non-invasively adapted to work with C++ coroutines.
-
James McNellis
Senior Software Engineer, Microsoft Visual C++
James McNellis is a senior engineer on the Visual C++ team at Microsoft, where he works on C++ library design and is responsible for the Microsoft C Runtime (CRT) and C Standard Library implementation. He can be found on Twitter at @JamesMcNellis and can be found elsewhere online via www.jamesmcnellis.com.
-
Videos Filmed & Edited by Bash Films: www.BashFilms.com
*-----*
Register Now For CppCon 2022: cppcon.org/registration/
*-----*
The year is 2024, 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 2022, and this is still one of the clearest talks about coroutines so far!
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.
I guess because it still is very confusing, especially to people who haven't done much async programming.
One of the best talks on cpp co routine.
8:00 I thought this was a trick question and this was a variable declaration 🤣
Why in the “let‘s look at future…” co_await after override that returns an awaiter can still be assigned to int?
This talk look alike to CppCon 2015: Gor Nishanov “C++ Coroutines - a negative overhead abstraction"
4:18 _state->conn_ is not declared anywhere.
At 4:00, is do_while function a recursive function?
Can someone provide a link to the talk "later this afternoon"? 38:03
Maybe a little late, but for future watchers: czcams.com/video/v0SjumbIips/video.html
Is a corouting same as Python functions using yield keyword ?
Yes, one application of them is Python-style generators.
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.
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.
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.
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++.
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.
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
Well that's disgusting. I feel like it would be better to not have coroutines yet than to have this.