How to interpret this operator "A pointer in a function must not represent ownership"

Based on this

Stroustrup suggests that "a pointer in a function should not represent ownership"

Question Can anyone give me a little detailed explanation? It is best if an example is illustrated.



source to share

3 answers

A pointer is "owned" by some code if that code is responsible for deleting it, or for transferring ownership to someone else. Various smart pointers implement explicit ownership patterns. shared_ptr

is several pieces of code that own a pointer. unique_ptr

represents only one piece of code that the pointer belongs to.

It says that if a function has a bare pointer (a pointer not in a smart pointer), it shouldn't be considered an owner. If it claims ownership of that pointer, it must either receive the smart pointer as a parameter, or it should have stored the pointer it created with the new

smart pointer.

He says that only smart pointers have pointers of their own. If a function accepts a naked pointer as a parameter, it does not require ownership of that pointer. If the function returns a naked pointer, you cannot claim ownership of that pointer.



std::unique_ptr<int> pOwner(new int(5)); // this is the owner
int* pAccess = pOwner.get(); // this is a weak accessor, it does not own anything


He talks about the role of raw pointers in the C ++ 11 world. Pointer owners must be shared_ptr

and unique_ptr

(they are owners because they are responsible for disposing of an object). Raw pointers must be used to access objects owned by the smart pointer. In C ++ 11, in principle, you will never have a reason to explicitly call delete

on a raw pointer.



When you create a dynamic object using new

, some other object will be responsible for removing it when it is no longer needed; this object is the "owner" of the dynamic object.

If you've always accessed an object using simple pointers, then it's hard to tell (without documentation) which of the pointer pointers is a property. If you are passing a pointer to a function, then does the function do? Or is the caller still responsible for removing it? If you make a mistake, then you either don't uninstall it (causing a resource leak, which can degrade the performance of your program and eventually stop working), or you can uninstall it too early (which can cause all sorts of errors, often very difficult to track).

A widely used solution for this is to have a policy to always use smart pointers (objects that look like pointers but contain logic to manage their target lifetime) to denote ownership and never delete anything you only have there is a simple pointer. Then there is never any confusion about whether to delete or not. The standard library provides smart pointers ( unique_ptr

and shared_ptr

) that provide common semantics owned by one entity and ownership shared between multiple objects.

This is one aspect of the broader topic of resource management through RAII , which is extremely important in C ++. In addition to enforcing a clear ownership model, it is also the only sane way to reliably prevent memory leaks when throwing exceptions.



All Articles