C++ Coroutines, from Scratch - Phil Nash - CppCon 2022

cppcon.org/
---
C++ Coroutines, from Scratch - Phil Nash - CppCon 2022
github.com/CppCon/CppCon2022
C++ 20 introduced coroutines into the language. Coroutines have the potential to greatly simplify some types of code - particularly, but not limited to, anything asynchronous in nature. But early adoption has been hindered by both the lack of library support in the standard and the inherent complexity of the feature itself (which, due to that lack of library support, you are typically more exposed to).
Now we have a bit of a “Blind men and an elephant” problem - where we’re getting disjointed glimpses of what coroutines, supposedly, are - without the big picture. I can’t claim to be able to give you a comprehensively big enough picture in a 60 or 120 minute talk, but my aim is to plot a journey through it by starting with a motivating example (a typical multiple async task problem), looking at how we might approach this without coroutines, then seeing what coroutines can do for us - and finally looking at what that would look like with library support.
---
Phil Nash
Phil Nash is the original author of the C++ test framework, Catch2, and composable command line parser, Clara. As Developer Advocate at SonarSource he’s involved with SonarQube, SonarLint and SonarCloud, particularly in the context of C++. He’s also a member of the ISO C++ standards committee, organiser of C++ London and C++ on Sea, as well as co-host and producer of the Cpp.chat and No Diagnostic Required podcasts.
More generally Phil’s an advocate for good testing practices, TDD and using the type system and functional techniques to reduce complexity and increase correctness. He’s previously worked in Finance and Mobile and offers training and coaching in TDD for C++.
__
Videos Filmed & Edited by Bash Films: www.BashFilms.com
CZcams Channel Managed by Digital Medium Ltd events.digital-medium.co.uk
#cppcon #programming #coroutines

[@DaMiK83]

I don't see how this is better of an explanation than any of the other coroutine talks so far.

[@ls.c.5682]

I agree. There's far too much fluff at the beginning - i'm about 11 minutes in and we haven't gone past the prologue of trying to explain the use case and background. We haven't touched coroutines at all yet

[@peterfordham3562]

It's not just another generator example that can be trivially implemented with a class.

[@MaceUA]

The most hard to follow Coroutines talk I've heard so far 🤯

[@Dziaji]

They all have been terrible except the 2 part one from a couple months ago from the guy with the Slavic accent.

[@joesilver75]

@@Dziaji I'm sure the guy has a name and the talk has a title.

[@randfur]

@@Dziaji Understanding C++ Coroutines by Example: Generators (Part 2 of 2) - Pavel Novikov?

[@lorenzobolis5166]

I like the idea of trying to introduce coroutines from a real example, but there is soooo much going on that it is very hard to follow (and I even work in quantitive finance, so I happen to know the domain, lingo a case presented...); as a coroutines novice, I didn't really learn much from this talk sadly :(

[@dekutree64]

Crash and burn. Gave up at 25 minutes.
Having used a custom coroutine system in video games, they're sort of like finite state machines, except your state is stored in the form of local variables on a personal stack. You can yield out from deep in a call stack and then jump back in next frame with the stack intact. So flow control is via standard function call/return, loops, if statements, etc. instead of having to create a bunch of state member variables so you can return all the way out to the top level every frame.

[@ZarviroffSerge]

This is a talk about json serialization. I'm on 20th minute, speaker is still talking about json serialization and still hasn't touched the topic of coroutines. I have doubts he ever will.

[@TheNikux]

I like this real world approach. Often these complex topics are illustrated with toy examples and it is hard to understand how to apply them on real world code.
This talk does not spend much time explaining what coroutines are on an abstract level and what are the coroutine types in the stdlib and what the methods do, though.
It would be nice to have the source code examples available to the public so we can study them.

[@lefteriseleftheriades7381]

I wanted to learn coroutined but fell asleep before he was done talking about modeling the derivatives

[@trejkaz]

C++ - taking a feature which is already hard to understand in other more modern languages, and making it even more obscure and hard to understand.

[@ps-ns2tv]

Loving this first slide 😂 giving the feel of coroutines in drawings... Thoughtful..

[@oschonrock]

Love the "real world flavour" approach. I think we need more of that. It's a big part of what makes our jobs interesting.. the code needs to do something real.

[@Dziaji]

Not for something complex like coroutines.The complexity of the use case obscures the basics of the feature he is attempting to teach "from scratch". Something like building simple generators or condensing a waterfall of web calls down to a flat function would have been better choices than this complex de-serialization of financial data example. The coder can apply the techniques to their own real world approach.

[@antonmakeyenko4018]

I've lost the track on 20 minute. And "we haven't touched coroutines yet"

[@BartKus]

Any point about coroutines completely lost in the complex objects and hierarchy.

[@TheTimur123]

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.

[@davidsicilia5316]

I think that coroutine tutorials are turning out to be just like monad tutorials: as soon as one understands them one immediately feels the desire to create yet another tutorial to top all of the others, and most of them end up being bad/ineffective or at best incomplete. I'm sure Phil had good intentions here, but I don't see how a nooby would be able to sit through this and learn anything meaningful about coroutines.

[@martijn-vels]

We spend 60% of our time from the start on a totally irrelevant and confusing "model" which appears to reflect some prior code by the speaker. Then we dive into somewhat naive abstractions supposed to help us transition into coroutine concepts. As someone who does understand coroutines, this is a bewildering and not very useful talk. There's way better tutorials out there.

[@esmeunomnodire]

25 minutes into the talk and haven't seen a coroutine yet. I'm sorry, but this talk could have been delivered better