It was when debugging a memory leak which occurred because I forgot to declare the base class destructor as virtual that I started to think C++ was a rather unfriendly language and not really designed to be easy to use. Then a few years later I read the spec for std::launder that I realised C++ was not really designed to be understood. It's a shame because it's actually a rather nice language in some ways. Here's hop…
Yeah... its shocking to me how difficult it is to read the C++ standard library. Surely, the standard library is written by the authors of the language. It should be a positive example of how they hope their language is used, right? Here's the source of C++'s vector class: https://gcc.gnu.org/onlinedocs/gcc-4.6.2/libstdc++/api/a0111... In comparison, vec in rust. (Note you need to scroll down a few pages to start see…
However you're being slightly unfair because Rust's Vec is just defined (opaquely) as a RawVec plus a length value, so let's link RawVec, https://doc.rust-lang.org/src/alloc/raw_vec.rs.html -- RawVec is the part responsible for the messy problem of how to actually implement the growable array type.
Still, the existence of three C++ libraries with slightly different (or sometimes hugely different) quality of implementation means good C++ code can't depend on much beyond what the ISO document promises, and yet it must guard against the nonsense inflicted by all three and by lacks of the larger language. In particular everything must use the reserved prefix so that it's not smashed inadvertently by a macro, and lots of weird C++ idioms that preserve performance by sacrificing clarity of implementation are needed, even where you'd ordinarily sacrifice to get the development throughput win of everybody know what's going on. For example you'll see a lot of "pair" types bought into existence which are there to squirrel away a ZST that in C++ can't exist, using the Empty Base Optimisation. In Rust the language has ZSTs so they can just write what they meant.