[tialaramex]

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.

[nemetroid]

> 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".

[gpderetta]

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.

[BenFrantzDale]

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.

[IiydAbITMvJkqKf]

Specifically, both shared_ptr and unique_ptr are owning pointers. Using plain old pointers for non-owning variables is idiomatic.

[tialaramex]

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.

[saagarjha]

> 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.

[tialaramex]

Yes, it's "just" a slice. Which is in fact one of the most obvious things you would want, and yet was not afforded by std::string.

[capitalsigma]

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`?

[tialaramex]

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.