Peter, I understand now. That is a brilliant feature of the shared_ptr design that allows an object to release itself while not being fully released until its member function returns (when the shared_ptr on the stack goes of scope). However, with a normal pointer this would not be safe - it would be very bad practice for an object that was not wrapped by a shared_ptr to release itself - this would result in an invalid this pointer. Locking the object before accessing is useful / essential when the object may want to destroy itself or even just to avoid run time errors when the programmer makes a mistake. However, I dont think it is necessarily a bad thing to forgo locking when the object is not meant to be able to release itself by design (in a ST environment). Valid_ptr is no where near as smart as a shared_ptr/weak_ptr, it works much more like a normal pointer, it takes a passive relationship to the object it points to, resulting in a more passive design. I think there are strong cases where the strengths of shared_ptr/weak_ptr are just not required and something between a normal and smart pointer is required.