3 ms·

> 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 mem

> 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.

account42 4y ago
> 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.
- colinsane 4y ago
  > 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.

account42 4y ago

> 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.

colinsane 4y ago
> 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.