This is made more confusing by C++ basically insisting that your "basic" built-in string type has to have the small string optimisation. The guts of std::string in any of the three popular stdlib implementations are... pretty complicated. In contrast Rust's String is literally just Vec<u8> [a growable array of bytes] plus a promise that these bytes are always a UTF-8 encoded string.

And by C++ taking a long time to get the natural string slice type, which it calls `std::string_view`. This type is what you almost always want in APIs that aren't responsible for growing and changing strings - for the names of things, labels, parsing and so on. Because this type was not in C++ 98 or C++ 11 or even C++ 14 people would use `std::string` instead even though they did not need to modify, let alone grow, the text or, since they don't want the overhead of `std::string`, they would use `char *`

It was correct for C++ to seek to do better than C here, but while what they delivered was a lot more powerful it's not clearly better and I think has contributed to widespread misunderstanding.

C++ doesn't require any of this. Everyone implements it this way because it is cheap and improves performance. And people don't take (const) char * they take const std::string &.