alt Hacker News> which guarantee that nothing gets deleted until there are no more references to it, and that at that point it will get deleted.
To be more precise, C++'s smart pointers will ensure something is live while specific kinds of references the smart pointer knows about are around, but they won't (and can't) catch all references. For example, std::unique_ptr ensures that no other std::unique_ptr will own its object and std::shared_ptr will not delete its object while there are other std::shared_ptrs around that point to the same object, but neither can track things like `std::span`/`std::string_view`/other kinds of references into their object.
Replies
I was just talking about ownership and smart pointers.
C++'s non-owning "view" classes are a different matter, and the issue there isn't ownership but lifetime of the view vs the underlying data the view is referencing (which in case of string_view could be literally anywhere - a local array of char, a malloc'd block of memory, etc!!).
I'm not a fan of a lot of the (relatively) more recent additions to C++. I think C++14 was about the peak! Given that C++ is meant to be usable as a systems programming language, not just for applications, and given that many new features being added to C++ are really library additions, not language ones, then it's important for the language to include unsafe lower level facilities than can be used for things like that, but actually encouraging application developers to use classes like this that are error-prone by design seems questionable!
> but neither can track things like `std::span`/`std::string_view`/other kinds of references into their object.
Sure, and if you get into it there are two issues here.
1) Smart pointers are a leaky abstraction that still gives you access to the underlying raw pointer if you want, with which you can shoot yourself in the foot.
2) It's not the smart pointer's fault, but the type you use them to point to might also be a leaky abstraction (e.g. std::string, which again allows access to the underlying raw pointer), or might just be some hot garbage the developer themselves wrote!
> std::unique_ptr ensures that no other std::unique_ptr will own its object
Literally all std::unique_ptr does is wrap the pointer. If we make two unique_ptrs which both think they own object X then not only will they both exist and point at X (so they don't actually ensure they're unique) they'll also both try to destroy X when they disenage e.g. at the end of a scope, leading to a double free or similar.
Uniqueness is a property you are promising, not one they're granting.
I expect you knew this, but it's worth underscoring that there is no magic here. This really is doing only the very simplest thing you could have imagined, it's a pointer but as an object, a "smart pointer" mostly in the same sense that if I add a cheap WiFi chip to this refrigerator and double the price now it's a "smart fridge".