shared_ptr<int> ptr = make_shared<int>(10);
int& val = *ptr;
ptr = make_shared<int>(20);
// val now points to freed memory
In the above code, I can read from and write to val which is pointing to freed memory. Same issue applies if we use .get() in shared_ptr. So, it is possible to shoot ourselves in the foot even if we resort to using smart pointers.
Nobody will code like above obviously. One way to hit this is if we have something like this -
class Foo {
public:
int& getVal() { return *p; }
private:
shared_ptr<int> p;
};
Someone can call getVal() after which some other member of the above class can choose to overwrite p with a different value. If getVal() above returns a shared_ptr instead of a reference, we will not see this issue. Some folks might argue that returning a shared_ptr is more expensive than returning reference since we need to increment the counter in the shared_ptr control block.
So, should the guideline be to not return a reference to a shared_ptr like above?
Aucun commentaire:
Enregistrer un commentaire