C++20 added minimal support for coroutines. I think they’re done in a way that really doesn’t fit into C++, mostly because they don’t follow the zero-overhead principle. Calling a…
See as a C# dev, all the time I think to myself l, “Proffessionally, you should pick up and really learn C++ mate”
Then I see blog posts like this where the author writes for pages and pages about how to get something as simple as await to work manually and I immediately am reminding why even after 11 years I still haven’t picked up C++ outside of little things for SBCs and whatnot.
I can see the fun in building such things by hand, but at a certain point I want to be able to actually start a project and jump straight into writing the application itself, and not need a tonne of boilerplate just to get modern functionality.
I will note for this statement:
This is less of a problem if your coroutines are long-lived.
Is typically true. Usually your coroutines (should) all spin up at the very start and all stay running for the entire app lifetime.
Usually, in my opinion, constantly spinning up and spinning down coroutines is a code smell, and us remedied with some form of pub/sub model where your “background” coroutines should always be running, and they just idle waiting at some kind of subscribed pipe for events to respond to and process.
That way you allocate everything you need at the start, then it all just sits and runs for the entire app lifespan.
Usually your coroutines (should) all spin up at the very start and all stay running for the entire app lifetime.
That’s an interesting perspective. At that point, what is even the point of coroutines over using threads? I thought the main reason for their existence was being lightweight enough to spin up whenever, wherever you need.
From the article, it seems that coroutines and “green threads” (e.g. goroutines and lua coroutines) are quite different things. As far as I understood, coroutines are just a way to pause/resume operation while retaining local scope state
Yes, alas C++ is fun, but very quirky. Perhaps too much. For big (new) projects I wouldn’t recommend it. People are trying to fix it but it’s hard and without breaking old features I don’t think it will be possible to make it better and improve it even more.
I’ve tried what you’re suggesting in order to write highly concurrent multi-threaded applications. I’ve used frameworks that are supposed to handle all the details of concurrency and synchronization for you. Inevitably they have flaws in their implementations where either the framework itself exhibits UB/data races/deadlocks, or else the design makes it far too easy to write your own UB/data races/deadlocks.
The worst part is that these problems usually don’t show themselves until your software has been running in production for thousands of hours, and then reproducing the problem to try to debug it is effectively impossible. I’ve had cases where I resort to building my C++ application in release with debug symbols and then run it inside of gdb in production. I haven’t benchmarked the effect of running it in gdb, but I have to imagine it kills much of the value of even using a high performance language.
Now I exclusively use Rust for any new development, and it’s never delivered any unwelcome surprises to me after deploying.
See as a C# dev, all the time I think to myself l, “Proffessionally, you should pick up and really learn C++ mate”
Then I see blog posts like this where the author writes for pages and pages about how to get something as simple as
awaitto work manually and I immediately am reminding why even after 11 years I still haven’t picked up C++ outside of little things for SBCs and whatnot.I can see the fun in building such things by hand, but at a certain point I want to be able to actually start a project and jump straight into writing the application itself, and not need a tonne of boilerplate just to get modern functionality.
I will note for this statement:
Is typically true. Usually your coroutines (should) all spin up at the very start and all stay running for the entire app lifetime.
Usually, in my opinion, constantly spinning up and spinning down coroutines is a code smell, and us remedied with some form of pub/sub model where your “background” coroutines should always be running, and they just idle waiting at some kind of subscribed pipe for events to respond to and process.
That way you allocate everything you need at the start, then it all just sits and runs for the entire app lifespan.
That’s an interesting perspective. At that point, what is even the point of coroutines over using threads? I thought the main reason for their existence was being lightweight enough to spin up whenever, wherever you need.
From the article, it seems that coroutines and “green threads” (e.g. goroutines and lua coroutines) are quite different things. As far as I understood, coroutines are just a way to pause/resume operation while retaining local scope state
Yes, alas C++ is fun, but very quirky. Perhaps too much. For big (new) projects I wouldn’t recommend it. People are trying to fix it but it’s hard and without breaking old features I don’t think it will be possible to make it better and improve it even more.
The only way to fix C++ is if you’re willing to break backwards compatibility and invent C++2.0.
But that already exists, and it’s called Rust.
@5C5C5C @SuperFola You don’t have to fix C++. Just use the appropriate level of abstraction. Else be happy that there is backward compatibility.
I’ve tried what you’re suggesting in order to write highly concurrent multi-threaded applications. I’ve used frameworks that are supposed to handle all the details of concurrency and synchronization for you. Inevitably they have flaws in their implementations where either the framework itself exhibits UB/data races/deadlocks, or else the design makes it far too easy to write your own UB/data races/deadlocks.
The worst part is that these problems usually don’t show themselves until your software has been running in production for thousands of hours, and then reproducing the problem to try to debug it is effectively impossible. I’ve had cases where I resort to building my C++ application in release with debug symbols and then run it inside of gdb in production. I haven’t benchmarked the effect of running it in gdb, but I have to imagine it kills much of the value of even using a high performance language.
Now I exclusively use Rust for any new development, and it’s never delivered any unwelcome surprises to me after deploying.