In C++ 03 they realise their pointer (inherited from C) is awful. Do they fix it? No, they add a new type named std::auto_ptr which is "smart". Thanks to operator overloading it can behave like the existing pointer. Kind of.
std::auto_ptr is pretty bad, and so in C++ 11 they deprecate auto_ptr and introduced std::shared_ptr and std::unique_ptr so now finally their language has halfway usable pointers, with these unwieldy names and some odd semantics you just have to get used to. C-style pointers remain all of: Simpler to use by virtue of their terse syntax, still necessary, and unsafe. std::auto_ptr still exists forever, but is officially deprecated.
At first C lacks strings, promoting string literals to a strange array with an extra zero value in it. Eventually C++ gets std::string and std::wstring but, nothing of value about these strings is defined, so they're both pretty useless and of course dangerous. In C++ 17 it gets std::string_view which finally expresses one of the things you probably first wanted, but it provides no enforcement of the most obvious expectation you have - C++ allows a string_view to outlive the underlying string, causing Undefined Behaviour. In C++ 20 you get to use ranged behaviour, and, that extra zero value bites you hard because of course you didn't mean the zero value but in C++ that's "part" of your string. They also, finally, decide that UTF-8 might be a good idea and define yet another type of string to mean UTF-8 encoded, about five years after everybody who matters was of course encoding strings as UTF-8.
> std::auto_ptr still exists forever, but is officially deprecated.
std::auto_ptr is fully removed since C++17.
I agree with most of your comment, but I think it reinforces the grandparent's point. The warts of std::string and null terminated strings are not "problems introduced by C++'s other recent additions".
Shared_ptr and unique_ptr are not replacement for raw C pointers. And the reason they are not blessed with language syntax is because user can and often do implement their own, so those two library types are not particularly special.
Agreed. And a huge strength of C++ is that you can write low-level classes like these and have them be fully performant and have reasonable native-feeling syntax. Almost no other languages provide that.
Non-owning pointers are a genuinely useful tool, but as a tool they're more welding torch than hammer, if that's what you needed it's really what you needed - but most often it probably isn't what you needed at all and will cause more harm than good.
So it's strange to provide them with stuff like terse built-in syntax, while not providing anything similar for the thing people will want all the time, ownership. Result: The Right Thing™ is harder to do and wastes visual space compared to the Wrong Thing. A "correct" program ends up full of boilerplate just to get what you'd obviously want.
> Eventually C++ gets std::string and std::wstring but, nothing of value about these strings is defined, so they're both pretty useless and of course dangerous. In C++ 17 it gets std::string_view which finally expresses one of the things you probably first wanted
Such as what? std::string_view represents exactly one thing, and that’s a slice into a string with a lifetime longer than it. That’s basically it. There aren’t really and other additional feature to it, so I feel like you may be confused as to what it does.
A lot of your criticism makes sense. I don't follow this one, though: `string_view` is *by definition` non-owning. Was non-owning the whole thing you wanted? If so, why are you surprised by lifetime issues? If non-owning isn't your main desire, what's wrong with `std::string`?
Probably in C++ context this feels unreasonable but I'm arguing that C++ is wrong here. It's OK for the language to enforce that the lifetime of the string underpinning a slice must equal or exceed the lifetime of the slice despite the slice not "owning" the string.
In 2011 there probably wasn't a mainstream non-GC language doing that. C++ would have been innovating here, and maybe C++ in 2011 didn't want to be innovating. By 2017 when C++ 17 introduces std::string_view it's behind the curve, this is not an exciting new feature, it's a weak imitation of what everybody else was already doing better.
std::auto_ptr is pretty bad, and so in C++ 11 they deprecate auto_ptr and introduced std::shared_ptr and std::unique_ptr so now finally their language has halfway usable pointers, with these unwieldy names and some odd semantics you just have to get used to. C-style pointers remain all of: Simpler to use by virtue of their terse syntax, still necessary, and unsafe. std::auto_ptr still exists forever, but is officially deprecated.
At first C lacks strings, promoting string literals to a strange array with an extra zero value in it. Eventually C++ gets std::string and std::wstring but, nothing of value about these strings is defined, so they're both pretty useless and of course dangerous. In C++ 17 it gets std::string_view which finally expresses one of the things you probably first wanted, but it provides no enforcement of the most obvious expectation you have - C++ allows a string_view to outlive the underlying string, causing Undefined Behaviour. In C++ 20 you get to use ranged behaviour, and, that extra zero value bites you hard because of course you didn't mean the zero value but in C++ that's "part" of your string. They also, finally, decide that UTF-8 might be a good idea and define yet another type of string to mean UTF-8 encoded, about five years after everybody who matters was of course encoding strings as UTF-8.