26

I recall reading somewhere that using references to smart pointers can cause memory corruption. Is this simply because of using the reference of the smart pointer after its been destroyed? Or does the reference counting get messed up?

Thanks for clarifying

coppro
  • 14,338
  • 5
  • 58
  • 73
Superpolock
  • 3,515
  • 7
  • 30
  • 24
  • It's the same reason storing references to other types of objects is bad, the object may get destroyed and you'll have a dangling reference. Smart pointers are supposed to keep the object they point to alive, but we're not talking about the pointed to object, we're talking about the smart pointer object itself. – bames53 Oct 26 '11 at 16:59
  • See http://stackoverflow.com/questions/327573/c-passing-references-to-boostshared-ptr – Jason Harrison Sep 18 '14 at 17:33

6 Answers6

15

Assuming you are talking about shared_ptr here...

Is this simply because of using the reference of the smart pointer after its been destroyed?

This is a good answer. You may not know absolutely the lifetime of the pointer your reference refers too.

To get around this, you'd want to look into boost::weak_ptr. It doesn't participate in reference counting. When you need to use it, it gives you a shared_ptr which goes away once your done with it. It will also let you know when the refered to pointer has been collected.

From the weak_ptr documentation

The weak_ptr class template stores a "weak reference" to an object that's already managed by a shared_ptr. To access the object, a weak_ptr can be converted to a shared_ptr using the shared_ptr constructor or the member function lock. When the last shared_ptr to the object goes away and the object is deleted, the attempt to obtain a shared_ptr from the weak_ptr instances that refer to the deleted object will fail: the constructor will throw an exception of type boost::bad_weak_ptr, and weak_ptr::lock will return an empty shared_ptr.

Note the method expired() will also tell you if your ptr is still around.

Doug T.
  • 64,223
  • 27
  • 138
  • 202
6

When using smart pointers (or any allocation management object) you are counting on the behaviors defined in the constructor/destructor to manage refs/derefs/locks/unlocks. As a result, those types of objects must be true objects to perform properly. when using references to such objects (or pointers) you are bypassing the mechanism (and asking for a wedgie).

Dan Hewett
  • 2,200
  • 1
  • 14
  • 18
4

There are still many cases in which a reference to a smart pointer is a good idea. An obvious example is the assignment method of the smart pointer class itself, which accept a reference to another smart pointer as its parameter.

Making a method that accepts a smart pointer reference means that the parameter doesn't increment the smart pointer's internal reference count. This can improve performance - but probably not a lot. Also, there are a lot of things the method cannot do with the reference - or the original smart pointer. If you know what these things are and avoid them, passing by reference works just fine. Of course, the purpose of smart pointers is to avoid having to know these things.

Also, if you have a method that will modify the value of a smart pointer parameter, passing as a reference is required, as it is with any other type.

Jeff B
  • 1,856
  • 2
  • 17
  • 28
1

The "smart" part of smart pointers is managed by the constructors, destructors, assigment operators, and other functions of the smart pointer class. By using a reference, you are circumventing these operations -- the constructor will not get called when your reference is initialized, and the destructor will not get called when your reference goes out of scope.

In essence, a reference to a smart pointer is a dumb pointer, with all the risks and gotchas that the latter entails.

JohnMcG
  • 8,709
  • 6
  • 42
  • 49
0

We have custom made smartpointers and we always make a habit of passing a 'const refsomething &'

it doesn't increment or decrement the smart pointer, and as such - and more importantly - calls to InterLockedIncrement/Decrement are avoided which in turns avoids a memory fence and all the things that go with that : bus locking, cache invalidation, ...

QBziZ
  • 3,170
  • 23
  • 24
  • The "Interlocked" function do **not** cause cache invalidation! – curiousguy Nov 27 '11 at 12:08
  • You are right. I was wrong. There would be no cache invalidation nor memory bus locking in this case. However if multiple threads are accessing this refcount, the number of lost cycles within the Interlocked... functions is rather non-deterministic and can be quite high. The effect could be even worse than a trashed cache. So there are good reasons to avoid them. – QBziZ Dec 15 '11 at 13:33
0

Passing a reference to a smart pointer into a function is perfectly safe and is a good idea. The object may go away but the smart pointer won't, it will be sat there saying null at least until the function returns. It is the best way to alias a smart pointer within its scope. If you use a reference with a const modifier on what it refers to then you have an intelligent observing reference: 

const smart_ptr<T>&

Interestingly and usefully, the const prevents you from using the reference to say, null the smart pointer and delete the object but it doesn't stop the original smart pointer from nulling itself and your reference will reflect that change.

Returning a reference to smart pointer from a function is asking for all sorts of trouble.

John Morrison
  • 1
  • 1