The thing is, they are even worse for performance than string implementations that store the length.. that extra few bits of memory is much cheaper than checking the size of a string everywhere. For example, copying a string with known length.
Also, c++’s strings even do some clever hacking where they store the text itself for shorter strings in the pointer, barring a pointer lookup. And this is possible only because abstraction.
They were designed when an extra byte or so per string cost you a lot of money. Nowadays, when 99% of the systems anyone will program start at 1MB RAM and 90% probably start at 512MB, they're a liability for almost no benefit.
You’ve got an extra byte either way, the \0 at the end. Which in many cases will make you copy a string because you can’t just “point” into a string literal and say take n chars from there. Of course I am not that old so I don’t have enough expertise — but seeming that every other language even at the time decided against it is pretty telling.
I think your parent was referring to the cost of storing a 2-byte string length instead of a 1-byte terminator. In the 1970s and 1980s, 2 bytes would likely be the minimum storage needed for the length of a general purpose string implementation. Although there were some language environments (e.g. Pascal) that had counted strings with a max length of 255.
Fair enough; but actually it can be more memory efficient as well because of the better reusability of substrings (in case of null-terminated ones only the end can be reused)
Also, c++’s strings even do some clever hacking where they store the text itself for shorter strings in the pointer, barring a pointer lookup. And this is possible only because abstraction.