If you need to implement an async state machine, couldn't that just as easily be done with std::future? How do coroutines make this cleaner/better?
This is why coroutine-based frameworks (e.g., C++20 coroutines with cppcoro) have largely superseded future-chaining for async state machine work — the generated code is often equivalent, but the source code is dramatically cleaner and closer to the synchronous equivalent.
(me: ex-Visual Studio dev who worked extensively on our C++ coroutine implementation)
Do you believe that std::future is the better option?
With the coroutine approach using yield, doesn't that mean the caller needs to decide when to call it again? With the std::future approach where it's event driven by the promise being set when that state/step has completed.
> "The only 'assembly' required is creating the associated promise"
Again, that is only true for one step. For a state machine with N states you need explicit state enums or a long chain of .then() continuations. You also need to the manage the shared state across continuations (normally on the heap). You need to manage manual error propagation across each boundary and handle the cancellation tokens.
You only get a "A nice readable linear flow" using std:future when 1) using a blocking .get() on a thread, or 2) .then() chaining, which isn't "nice" by any means.
Lastly, you seem to be conflating a co_yield (generator, pull-based) with co_await (event-driven, push-based). With co_await, the coroutine is resumed by whoever completes the awaitable.
But what do I know... I only worked on implementing coroutines in cl.exe for 4 years. ;-)
What I was thinking of as a state machine with using std::future was a single function state machine, using switch (state) to the state specific dispatch of asynch ops using std::future, wait for completion then select next state.
I don't even know how to respond to that. How in the world are you using C++ professionally if you think coroutines are "daunting"? No one uses C++ for it's "convenience" factor. We use it for the power and control it affords.
> What I was thinking of as a state machine with using std::future was a single function state machine, using switch (state) to the state specific dispatch of asynch ops using std::future, wait for completion then select next state.
Uh huh. What about error propagation and all the other very real issues I mentioned that you are just ignoring? Why not just let the compiler do all the work the way it was spec'ed and implemented?
Sounds more like punishment than software design, but each to their own.
It’s pretty clear you’ve never built a production-grade async state machine.
C++ is designed to provide the plumbing, not the kitchen sink. It’s a language for building abstractions, not handing them to you — though in practice, there’s a rich ecosystem if you’d rather reuse than reinvent.
That flexibility comes at the cost of convenience, which is why most new engineers don’t start with C++.
What you call “intimidating,” I call powerful. If coroutines throw you off, you’re probably using the wrong language.
Last thought — when you run into someone who’s built the tools you rely on, ask them questions instead of trying to lecture them. I would have been more than happy to work through a pedagogical solution with you.
/ignored
Haha .. you have no idea.
FWIW I've built frameworks exactly for that, and it's highly likely that you've unwittingly used one of them.
But yeah, if you want to win arguments then arguing against yourself and your own hallucinations, is in your case the best way to go.
> computer systems whose backend implementations you are blissfully ignorant of
I am extremely confident in my "backend" knowledge (of course, an actual systems engineer would never refer to their work as "backend").
You wrote a "C++ framework" that runs in the "backend" of a "computer system"? Do I have that right? Please let me know what it is so that I can decompile it and see how it was implemented!
Probably not.
You seem to be struggling with technical language.
But sure... let's keep going while you do nothing but whine without displaying any technical acumen. This is fun!
Why don't you hop into the discussion of the early Windows ring-3-to-ring-0 transition issues [0] we had in the 90s? You know... since I am "blissfully ignorant" about internals. I can't wait to learn from your "backend" expertise!!
How old are you? 14?
Bye!
One of us worked on two of the most popular development tools of all time, and the other makes shit up and refuses to engage with technical details.
Also, since you know what I've worked on, it should be pretty obvious how old I am.