   [Boost] Direct dereferencing a shared_ptr.
  Hi.I have a thought about derefencing a shared_ptr which would be very handy when I would need the actual object(or C++ reference to it) directly.Like this:std::vector<boost::shared_ptr<SomeObject> > sharedPtrVecObjects;// Here:SomeObject &directRefObject = *sharedPtrVecObjects[someIndex];But I'm unsure if I really can do that because I suspect doing so would cause a bug which would increase the reference count for a shared_ptr instance that "gets" lost.So I wonder if that so?Thanks.   
  Dereferencing a shared_ptr won't increase the reference count.   ;  I'm not seeing why that would be wrong in the general case.At least I don't see any problem with usages like:void Foo(X& x);shared_ptr<X> x(new X);Foo(*x);The reference is not an owner of the pointer, it's just using the object, so why should it increase the reference count.(Perhaps it would be different in multi-threaded programs, where it might be safer to use a weak_ptr instead?)   ;  Thank you SiCrane that was very fast.Then that's exelent it's safe to do so.Is there some work around code for that in shared_ptr which makes that sure.   ;Quote:Original post by visitorI'm not seeing why that would be wrong in the general case.At least I don't see any problem with usages like:void Foo(X& x);shared_ptr<X> x(new X);Foo(*x);The reference is not an owner of the pointer, it's just using the object, so why should it increase the reference count.(Perhaps it would be different in multi-threaded programs, where it might be safer to use a weak_ptr instead?)Yes you're right. Of coarse it's safe to do that. But now I remembered my issue as it really was.That I was thinking of were if I have an internal 'get' function that returns a shared_ptr and one directly deference that function.Like so:boost::shared_ptr<SomeObject> SomeObjectContainer::getSomeObject(Uint32 index){    return sharedPtrVecObjects[index];} . . . SomeObjectContainer someObjectCon;// Using:SomeObject &directRef = *someObjectCon.getSomeObject(someIndex);That would probably cause it.;  Yes, the reference count would increase, as you copy a shared_ptr to return it. But when the expression is evaluated, the temporary shared_ptr is destroyed and decreases the reference count. The receiving reference would still be referencing an object at *sharedPtrVecObjects[someIndex].If the intended usage is to take a plain reference to an object in the container, and the users don't want or need to participate in managing to object's memory, IMO, the container could just hand out references directly.   ;  So that's really safe that too. Good, that's what I needed to know. Thanks!Quote:If the intended usage is to take a plain reference to an object in the container, and the users don't want or need to participate in managing to object's memory, IMO, the container could just hand out references directly.Yes, but if you need functions that return both a shared_ptr and a plain reference you can just define the one for shared_ptr, because getting the other one is just to derefence it by just placing '*' before the call. So no need for them two to be defined.   ;  shared_ptr has a member function get() which returns raw pointer.Quote:(Perhaps it would be different in multi-threaded programs,shared_ptr is thread safe by itself. Manipulating raw pointers obviously requires caution, but there is nothing language or shared_ptr can do about it.   