2 ms·

When people use the delete operator manually and mess up, do they usually delete objects too early or too late? In my experience, they usually delete objects to

When people use the delete operator manually and mess up, do they usually delete objects too early or too late? In my experience, they usually delete objects too late or not at all (though I admit to not having hard data here). Accordingly, most of the benefits people cite regarding RAII classes such as unique_ptr are that they reduce memory leaks. I would agree that they do. But memory leaks aren't nearly as severe as use-after-free. Additionally, it's not really shared ownership that causes problems; it's the fact that references (and pointers) make it possible to violate ownership semantics. References are used all the time in C++, and you can't use any libraries without them. It doesn't matter if data has a single owner if that owner is deleted and you still hold references to the data. In fact, shared ownership via shared_ptr is safer than unique_ptr, from a UAF point of view.

jupp0r 8y ago
> Additionally, it's not really shared ownership that causes problems; it's the fact that references (and pointers) make it possible to violate ownership semantics. Shared ownership makes it much harder to reason about lifetimes, increasing the chance of mistakes. > shared ownership via shared_ptr is safer than unique_ptr, from a UAF point of view. Only if the dereferencing code holds the shared_ptr. It's also common to pass non-owning pointers to objects held by shared_ptr. > When people use the delete operator manually and mess up, do they usually delete objects too early or too late? As you pointed out, problems arise if objects are deleted too early or twice. Double free is common in C and can be exploited as well...