Not OP but I think it depends on your definition of 'string'. For example there are some very grumpy devs who believe that C has no strings, and that "const char*" cannot ever be considered a string, and that anyone else who claims so is wrong.

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.