Deciphering C++ Coroutines - A Diagrammatic Coroutine Cheat Sheet - Andreas Weis - CppCon 2022
Vložit
- čas přidán 20. 10. 2022
- cppcon.org/
---
Deciphering C++ Coroutines - A Diagrammatic Coroutine Cheat Sheet - Andreas Weis - CppCon 2022
github.com/CppCon/CppCon2022
Coroutines are a powerful addition to C++20, allowing developers to drastically simplify code for certain kinds of problems and be adapted to a wide range of different use cases. But anyone trying to familiarize themselves with them will quickly notice that this flexibility comes at a price: In their current state, C++ coroutines are notoriously difficult to learn and their tight integration with the compiler gives them a feel quite unlike any other feature in the language.
The goal of this talk is to give a sustainable introduction on how to read and reason about coroutine code. We will learn how all the different elements of the mechanism fit together and to distinguish the parts of the code that follow the new rules of coroutines from those that still follow the well known conventional rules of C++. We will approach this through the construction of a coroutine cheat sheet, a collection of diagrams that serve as visual maps for navigating the complexities of the feature. Special care is taken to provide visual cues that are easily recognizable later on, to compensate for the fact that learners tend to forget the numerous details of the mechanism very fast if they don't use it in their everyday coding.
To account for the complexity of the topic, this talk focuses exclusively on providing a comprehensive introduction to the coroutine syntax, without discussing any advanced use cases. However, with the knowledge obtained from this talk, attendees will be able to easily follow more advanced presentations of coroutines later on without getting lost in the technical details of its peculiar syntax.
---
Andreas Weis
Andreas Weis has been writing C++ code in many different domains, from real-time graphics, to distributed applications, to embedded systems. As a library writer by nature, he enjoys writing portable code and exposing complex functionalities through simple, richly-typed interfaces. Both of which C++ allows him to do extensively. Andreas is also one of the co-organizers of the Munich C++ User Group, which allows him to share this passion with others on a regular basis.
He currently works for Woven Planet, where he focuses on building modern software for use in safety critical systems.
__
Videos Filmed & Edited by Bash Films: www.BashFilms.com
CZcams Channel Managed by Digital Medium Ltd events.digital-medium.co.uk
#cppcon #programming #coroutines - Věda a technologie
I used to think, like others (apparently), that coroutines seem way more complex than they needed to be. But, as I learn more about them, I realize that this language feature was added in such a way as to provide maximum flexibility, so that it could support any type of coroutine-based library that one could think of. It's like how, at the beginning, pointers and templates seem to over complicate things, and then you have an "aha!" moment, and then their complexity makes sense.
One of the main ideas that helps me understand the purposes of coroutines is that each coroutine can be used to create related *families* of functions. For example, the Generator coroutine is just 1 coroutine type, but that allows you to create any amount of functions that need to behave like generators. That allows us to place the complexity of yield/waiting within the Generator coroutine, and then each function only needs to deal with generating the actual values.
I have no doubt that, as we become more experience in using coroutines as a community, we'll start to see libraries that make novel uses of the machinery that coroutines provide. It's a very powerful feature, but with that power comes associated complexity.
There are 2 aspects of coroutines: how to use them, and how to create them. I think it's ok to just learn how to use them at first, and only learn how to create them as you find need for them. Unless, like me, you're intrigued by them, in which case you'll have to deal with the process of learning this powerful feature.
I would only point out that pointers are not high level abstractions adding complexity, on the other hand named objects are abstrations of pointers. It's basically all pointers down at the machine level.
This talk is fantastic. It goes through each part of the coroutine machinery in detail. It really helped me understand various things that I was still confused about.
However, this is not the best talk for beginners. For someone completely unfamiliar with coroutines, they should watch other beginner talks first, and then come to this one to round out the knowledge. Thank you, Andreas Weis.
I've watched the talk twice. The second time I understood everything that was presented. Kudos to Andreas Weis for the great presentation.
The ever best tutorial of c++ coroutines. Visualizing the components and correlations make sense a lot!!!! Thx for amazing talk!
This is a very well thought out picture / diagram of the whole coroutine concept. Thank you for the much effort to make this happen.
If you are having trouble understanding this wonderful talk, note that these are the building blocks of any coroutine applications. Check first out some finished products of these building blocks like cppcoro and you will notice all the possibilities that these constructs provide.
Thank you, very useful lecture
Hey, where to access the slides of this talk? I am unable to find them in the CPPCon 2022 github link provided in the description..
Really nice lecture🎉!!
Literally “deciphering “ 😂
Pushing data into a coroutine and symmetric transter topics were missing parts for me. Thank you for explanation.
Not sure if i understand correctly, but seems foundamentally coroutine is just a more elegant way to wrap up the callback. where you have the coroutine handler that connects the caller and callback...
sounds like it exposes a kind of customizable shallow context switching, idk, kind of reads to me like the designers were trying to elevate low level implementation details to a first-class language feature but ended up getting a little too carried away with the gee-wiz of it all
Based on this... co-routines seems more like a mutable lambda or a function object with multiple () overloads, with co_return, runs a destructor with a return type ...
Isn't it better to have coroutines use observer pattern with promise being a central point and the coroutines_handler as abstract pattern.
This way most of the complexity of the coroutines would be removed for applications developers point of view.
I have yet to see a talk about co-routines that explains why I would use a co-routine.
What has been helping me with this is writing code to implement little pieces of coroutines. As one gains knowledge of the various pieces, ideas on how to use them will naturally arise.
It’s my understanding it’s so you can make async calls in your code, that appear to be synchronous, without having to implement callbacks. In theory, your code looks sequential and blocking but it’s not.
I’m comparing to what I can do in JavaScript, with async/await, compared to using promises with a bunch of “then” statements chained together. However, sure does seem like we have to write a bunch of ReturnType-specific code to accomplish this. I need to understand this better before I’m sold…
I wish they showed the Fibonacci generator in the multiple forms with co_await, co_yield and another coroutine.
I like coroutine and I have created an echo server with it with wrapping the epoll. But the question is, C++ gives a basic functionality but the exector and utilities around it. The community shows less interest at it. The async ecosystem is even worse than Rust's.
Do I understand correctly that the coroutines allow us to return an unfinished result that will appear in the future, but unlike the standard future promise that we have in std::async, we do not hang on the get() method. Thus, the coroutines allow us to make chains of functions where the result of the first function is not yet ready for processing in the second function, while we do not hang on the get() method waiting for the finished result. The same can be done with monadic chain, when we build a pipeline of transformation chains. It's very similar to a car factory. There is a conveyor and there are many machines. Each machine takes the result from the previous one and passes it to the next one. But when there is no input part yet, the machine is NOT IDLE, it begins to do preparatory operations, for example, before installing wheels, it is necessary to take the correct mounting bolts. There is nothing prevents from taking 20 bolts out of the box for fixing the wheels, even if the wheels has not yet arrived from the air pumping machine, which pumps the wheel with air. Thus, the machine for installing wheels will already have time to do something (in other words, it will start its work even the wheel is not ready yet). As soon as the previous machine gives the finished wheels, the machine that installs the wheels on the car will immediately tighten them with ready at hands bolts, since it has already found and taken these bolts during the time while the previous machine was pumping the wheels. Thus, no one is idle waiting for the result from the previous machine.
I am a bad student :) but I also think that too much stuff was left out to make it fit in 60 min...
Also I would like to see those graphs and sequence diagrams even if author thinks they are inferior to colored code.
This is the best presentation on c++ co-routines that I have seen so far. Unfortunately, it is still complete cryptic garbage and is disjointed and not understandable. All the pieces are described without explaining what they are or why they are necessary or what they have to do with co-routines. I suspect that part of the problem is the over-complication of the language feature, leading to difficulty in properly explaining how it works, but even the most complicated concept can be broken down into pieces and organized into a digestible presentation. While I commend this guy for his effort, the presentation collapses into a jumbled, unintelligible mess of terms that leaves me no closer to being able to read or write co-routine inner workings. Hopefully, someone else will try again. Maybe someone can get Scott Meyers on the job.
Nobody really explains schedulers, and STL also misses at least some generic specification for those. So you have a very featureful tool to stop and resume the function but nobody really explains how to approach to design something that actually executes them! This makes corountines pointless for many potential users.
I completely disagree. This talk was fantastic. It's very difficult to learn coroutines without writing test code for implementing coroutines, and trying things out as the various speakers brings them up. Coroutines require experimentation to be propertly understood -- it's not a passive process. I've been listening to as many coroutine talks as I can, and each brings me closer to full comprehension. This talk, in particular, filled out some holes I had in my understanding.
C++ was able to turn this clean and modern feature into a hot garbage complex mess that nobody will use...
I have like a ton questions.... however the main point is, it will be ignored for next 10 years, unless someone pays to use it.
This is all extremely convoluted and unbelievably ugly. I will go to great lengths before I put any of this clusterfuck in my code. I'd rather make a state machine, use an explicit "recursion" stack, or whatever else it takes. Coroutines are powerful as a concept, and can be elegant in a language which fits them. C++ fits the machine, and the machine does not work like that. If you need an hour-long video to explain a single language feature, that should ring an alarm bell. The C++ committee has seriously lost the plot by this point.
From C++98 to C++17 I've been routinely impressed by how carefully each standard specification had been thought thru. The language always stood out for its clarity and precision. With the introduction of forwarding references, C++ lost some points in clarity because arguments of template functions can now forego the const specifier in order to coalesce into the same syntax both l-value references (usually const) and r-value references (usually non const), muddling clarity. The introduction into the standard of trailing declarations (e.g. auto f() -> int) was mostly a hipster stunt to impress the groundlings. But most worryingly, the C++20 and C++23 specifications contributed to by Google are taking the language off its orbit of mental sanity and into utter brainfuckery, with a growing exceptions-to-rules ratio.
megamind
very bad explanation. No real samples.
I don't recommend this as a starting point for c++ coroutines.