I write of code in both C# and C++ daily, have been doing it for ~15 years now, and maintaining an ancient codebase. I generally agree with TheRealPomax. C++ has problems but I personally find it more ergonomic than Rust (less than C# though) and I personally never had a memory issue in my own code. In other people's code, yes, there were some subtle ones, but I usually found those pretty quickly. It's not a perfect or even a good language, but IMO not a complete disaster.

I have this opinion. I much prefer C++ to Go and Rust. There need to be languages that don’t hold your hand - you can argue instead that C++ is an incorrect language choice for many projects and I’d agree with you though

Once you understand lifetimes well C++ is a joy to write. 99% of all the complaints about C++ are 1. lack of automatic bounds checking, which is trivial to implement yourself 2. memory management problems because people have a poor mental model of how it works, which can be learned.

> 99% of all the complaints about C++ are … 2. memory management problems because people have a poor mental model of how it works, which can be learned.

or memory management problems because Qt uses a different string type than glib uses a different string type than std, each with different ownership semantics, and by the way some of these claim to be thread-safe while others don’t say clearly one way or the other in the docs, except actually Qt’s copy-on-write implementation claims to be thread safe but assumes that the compiler inlines the mutation operators so if you forward-declare `struct QString` instead of #include <QString> then the operations might not be thread-safe…

i think the CoW problem might have been with Qt’s set type, not its string type, but you get the idea. it’s not just the language: it’s the library ecosystem too. it’s that any time i dive into contributing to a new C++ project i have to learn potentially a new memory model, one which is likely assumed instead of documented.

RAII presented an opportunity to normalize all this stuff; i’m not sure how significantly it’s unified things: i suspect it’s effective primarily in greenfield projects.

> Qt uses a different string type than glib uses a different string type than std

That is true for any language, even C, so your complaint is with those libraries not the language - and glib isn't even a C++ library at all while Qt is an ancient library that cares more about source-compatibility with its earlier versions than modern C++ (or even any version of C++ with a std::string).

> except actually Qt’s copy-on-write implementation claims to be thread safe but assumes that the compiler inlines the mutation operators so if you forward-declare `struct QString` instead of #include <QString> then the operations might not be thread-safe…

That doesn't make any sense. How is inlining going to affect thread safety? And (only) forward declaring a type won't let you do any mutations since at that point it's just an opaque name withoutout any known members.

> it’s not just the language: it’s the library ecosystem too.

And a new language won't fix that - especially when your idea of the library ecosystem for C++ already includes C libraries.

> glib isn't even a C++ library

glibmm

i’m sorry that i’m fuzzy on my Qt CoW issue. it was 8 years ago or so, i could probably dig up the ticket about it but the point was that thread-safety is just a thing you’re guessing at whenever you’re using C++. other languages have radically reduced that guesswork.

>> it’s not just the language: it’s the library ecosystem too.

> And a new language won't fix that - especially when your idea of the library ecosystem for C++ already includes C libraries.

that doesn’t match my experience. taking the C++ codebases i’ve contributed to, more use a non-std string type than do. e.g. LMMS uses QString, Stepmania uses its “rage” rstring type. neither of these are small projects, both have download counts in the multi-millions.

new languages do address these problems. when i see a project in Rust (or Go, Typescript, …) that i’m thinking of contributing to, i can be fairly confident it’s using the standard String type and that i can come up-to-speed on its memory model instantly — when i see that same project written in C++ i don’t know if it’ll take 10 minutes or 10 hours to understand its memory model, and believe me that uncertainty does impact which projects i choose to contribute to today.

You did not claim that C++ had no problems, just that you prefer it. No fight from me. You should be able to like what you want.

While not a shot at your choice, a C++ dev that I follow a bit is the creator of SerenityOS. Many times and in many of his YouTube videos he has sung the praises of C++ and called it his favourite language. Presently, he is writing his own language, Jakt, to replace it. I find that interesting.

>memory management problems because people have a poor mental model of how it works, which can be learned.

But that has to be learned for each CPP file separately.

> Once you understand lifetimes well C++ is a joy to write.

Well, so is Rust. You even have usable macros and templates that are't cancer to write.

Hi, I disagree, nice to meet you

I wrote plenty of code in Qt and C++ (up to around C++11) and I don't think it was that bad. I then moved on to JS / PHP (purely for money) and now Rust.

C++ is not that bad. Templates can be a bit hairy and slow.

Now that we have Rust to compare, having safety would be nice. It wasn't an option back then. You were either shooting yourself with undefined in scripting languages or with null pointers in C/C++. Having a dependency manager a-la npm or cargo would be nice, but it was never an option in the past.

But things are mostly fine.