this post was submitted on 06 Apr 2024
21 points (100.0% liked)

C++

1721 readers
16 users here now

The center for all discussion and news regarding C++.

Rules

founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] pixxelkick 5 points 5 months ago* (last edited 5 months ago) (6 children)

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.

[–] [email protected] 1 points 5 months ago (3 children)

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.

[–] [email protected] 6 points 5 months ago (2 children)

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.

[–] [email protected] 1 points 5 months ago (1 children)

@5C5C5C @SuperFola You don't have to fix C++. Just use the appropriate level of abstraction. Else be happy that there is backward compatibility.

[–] [email protected] 2 points 5 months ago* (last edited 5 months ago)

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.

load more comments (2 replies)