When is std weak ptr useful

Question

I started studying smart pointers of C  11 and I don t see any useful use of std  weak ptr  Can someone tell me when std  weak ptr is useful necessary

User · Answer

There is a drawback of shared pointer  shared pointer can t handle the parent-child cycle dependency  Means if the parent class uses the object of child class using a shared pointer  in the same file if child class uses the object of the parent class  The shared pointer will be failed to destruct all objects  even shared pointer is not at all calling the destructor in cycle dependency scenario  basically shared pointer doesn t support the reference count mechanism    This drawback we can overcome using weak pointer

User · Answer

When using pointers it s important to understand the different types of pointers available and when it makes sense to use each one  There are four types of pointers in two categories as follows    Raw pointers     Raw Pointer   i e  SomeClass  ptrToSomeClass   new SomeClass        Smart pointers     Unique Pointers   i e   std  unique ptr lt SomeClass gt  uniquePtrToSomeClass   new SomeClass         Shared Pointers   i e   std  shared ptr lt SomeClass gt  sharedPtrToSomeClass   new SomeClass          Weak Pointers   i e   std  weak ptr lt SomeClass gt  weakPtrToSomeWeakOrSharedPtr   weakOrSharedPtr          Raw pointers  sometimes referred to as  legacy pointers   or  C pointers   provide  bare-bones  pointer behavior and are a common source of bugs and memory leaks  Raw pointers provide no means for keeping track of ownership of the resource and developers must call  delete  manually to ensure they are not creating a memory leak  This becomes difficult if the resource is shared as it can be challenging to know whether any objects are still pointing to the resource  For these reasons  raw pointers should generally be avoided and only used in performance-critical sections of the code with limited scope   Unique pointers are a basic smart pointer that  owns  the underlying raw pointer to the resource and is responsible for calling delete and freeing the allocated memory once the object that  owns  the unique pointer goes out of scope  The name  unique  refers to the fact that only one object may  own  the unique pointer at a given point in time  Ownership may be transferred to another object via the move command  but a unique pointer can never be copied or shared  For these reasons  unique pointers are a good alternative to raw pointers in the case that only one object needs the pointer at a given time  and this alleviates the developer from the need to free memory at the end of the owning object s lifecycle   Shared pointers are another type of smart pointer that are similar to unique pointers  but allow for many objects to have ownership over the shared pointer  Like unique pointer  shared pointers are responsible for freeing the allocated memory once all objects are done pointing to the resource  It accomplishes this with a technique called reference counting  Each time a new object takes ownership of the shared pointer the reference count is incremented by one  Similarly  when an object goes out of scope or stops pointing to the resource  the reference count is decremented by one  When the reference count reaches zero  the allocated memory is freed  For these reasons  shared pointers are a very powerful type of smart pointer that should be used anytime multiple objects need to point to the same resource    Finally  weak pointers are another type of smart pointer that  rather than pointing to a resource directly  they point to another pointer  weak or shared   Weak pointers can t access an object directly  but they can tell whether the object still exists or if it has expired  A weak pointer can be temporarily converted to a shared pointer to access the pointed-to object  provided it still exists   To illustrate  consider the following example    You are busy and have overlapping meetings  Meeting A and Meeting B You decide to go to Meeting A and your co-worker goes to Meeting B You tell your co-worker that if Meeting B is still going after Meeting A ends  you will join The following two scenarios could play out    Meeting A ends and Meeting B is still going  so you join Meeting A ends and Meeting B has also ended  so you can t join    In the example  you have a weak pointer to Meeting B  You are not an  owner  in Meeting B so it can end without you  and you do not know whether it ended or not unless you check  If it hasn t ended  you can join and participate  otherwise  you cannot  This is different than having a shared pointer to Meeting B because you would then be an  owner  in both Meeting A and Meeting B  participating in both at the same time    The example illustrates how a weak pointer works and is useful when an object needs to be an outside observer  but does not want the responsibility of sharing ownership  This is particularly useful in the scenario that two objects need to point to each other  a k a  a circular reference   With shared pointers  neither object can be released because they are still  strongly  pointed to by the other object  When one of the pointers is a weak pointer  the object holding the weak pointer can still access the other object when needed  provided it still exists

User · Answer

When we does not want to own the object   Ex    class A       shared ptr lt int gt  sPtr1      weak ptr lt int gt  wPtr1      In the above class wPtr1 does not own the resource pointed by wPtr1  If the resource is got deleted then wPtr1 is expired   To avoid circular dependency   shard ptr lt A gt   lt ----  shared ptr lt B gt   lt ------                                                                                                                                                                                                                   class A                 class B                                                                       ------------                                                          -------------------------------------   Now if we make the shared ptr of the class B and A  the use count of the both pointer is two   When the shared ptr goes out od scope the count still remains 1 and hence the A and B object does not gets deleted   class B   class A       shared ptr lt B gt  sP1     use weak ptr instead to avoid CD  public      A      cout  lt  lt   A     lt  lt  endl         A     cout  lt  lt    A     lt  lt  endl         void setShared shared ptr lt B gt  amp  p                sP1   p            class B       shared ptr lt A gt  sP1   public      B      cout  lt  lt   B     lt  lt  endl         B     cout  lt  lt    B     lt  lt  endl         void setShared shared ptr lt A gt  amp  p                sP1   p            int main         shared ptr lt A gt  aPtr new A       shared ptr lt B gt  bPtr new B        aPtr- gt setShared bPtr       bPtr- gt setShared aPtr        return 0        output   A   B     As we can see from the output that A and B pointer are never deleted and hence memory leak   To avoid such issue just use weak ptr in class A instead of shared ptr which makes more sense

User · Answer

I see a lot of interesting answers that explain reference counting etc   but I am missing a simple example that demonstrates how you prevent memory leak using weak ptr  In first example I use shared ptr in cyclically referenced classes  When the classes go out of scope they are NOT destroyed   include lt iostream gt   include lt memory gt  using namespace std   class B   class A   public      shared ptr lt B gt bptr      A             cout  lt  lt   quot A created quot   lt  lt  endl             A             cout  lt  lt   quot A destroyed quot   lt  lt  endl            class B   public      shared ptr lt A gt aptr      B             cout  lt  lt   quot B created quot   lt  lt  endl             B             cout  lt  lt   quot B destroyed quot   lt  lt  endl            int main                   shared ptr lt A gt  a   make shared lt A gt             shared ptr lt B gt  b   make shared lt B gt             a- gt bptr   b          b- gt aptr   a             put breakpoint here    If you run the code snippet you will see as classes are created  but not destroyed  A created B created  Now we change shared ptr s to weak ptr  class B  class A   public      weak ptr lt B gt bptr       A             cout  lt  lt   quot A created quot   lt  lt  endl             A             cout  lt  lt   quot A destroyed quot   lt  lt  endl            class B   public      weak ptr lt A gt aptr       B             cout  lt  lt   quot B created quot   lt  lt  endl             B             cout  lt  lt   quot B destroyed quot   lt  lt  endl                int main                               shared ptr lt A gt  a   make shared lt A gt                 shared ptr lt B gt  b   make shared lt B gt                 a- gt bptr   b              b- gt aptr   a                     put breakpoint here        This time  when using weak ptr we see proper class destruction  A created B created B destroyed A destroyed

User · Answer

Another answer  hopefully simpler   for fellow googlers   Suppose you have Team and Member objects   Obviously it s a relationship   the Team object will have pointers to its Members  And it s likely that the members will also have a back pointer to their Team object   Then you have a dependency cycle  If you use shared ptr  objects will no longer be automatically freed when you abandon reference on them  because they reference each other in a cyclic way  This is a memory leak   You break this by using weak ptr  The  owner  typically use shared ptr and the  owned  use a weak ptr to its parent  and convert it temporarily to shared ptr when it needs access to its parent   Store a weak ptr    weak ptr lt Parent gt  parentWeakPtr    parentSharedPtr     automatic conversion to weak from shared   then use it when needed  shared ptr lt Parent gt  tempParentSharedPtr   parentWeakPtr  lock       on the stack  from the weak ptr if   tempParentSharedPtr          yes  it may fail if the parent was freed since we stored weak ptr   else        do stuff      tempParentSharedPtr is released when it goes out of scope

User · Answer

A good example would be a cache   For recently accessed objects  you want to keep them in memory  so you hold a strong pointer to them  Periodically  you scan the cache and decide which objects have not been accessed recently  You don t need to keep those in memory  so you get rid of the strong pointer   But what if that object is in use and some other code holds a strong pointer to it  If the cache gets rid of its only pointer to the object  it can never find it again  So the cache keeps a weak pointer to objects that it needs to find if they happen to stay in memory   This is exactly what a weak pointer does -- it allows you to locate an object if it s still around  but doesn t keep it around if nothing else needs it

User · Answer

Apart from the other already mentioned valid use cases std  weak ptr is an awesome tool in a multithreaded environment  because    It doesn t own the object and so can t hinder deletion in a different thread std  shared ptr in conjunction with std  weak ptr is safe against dangling pointers - in opposite to std  unique ptr in conjunction with raw pointers  std  weak ptr  lock   is an atomic operation  see also About thread-safety of weak ptr    Consider a task to load all images of a directory   10 000  simultaneously into memory  e g  as a thumbnail cache   Obviously the best way to do this is a control thread  which handles and manages the images  and multiple worker threads  which load the images  Now this is an easy task  Here s a very simplified implementation  join   etc is omitted  the threads would have to be handled differently in a real implementation etc      a simplified class to hold the thumbnail and data struct ImageData     std  string path    std  unique ptr lt YourFavoriteImageLibData gt  image         a simplified reader fn void read  std  vector lt std  shared ptr lt ImageData gt  gt  imagesToLoad        for  auto amp  imageData   imagesToLoad        imageData- gt image   YourFavoriteImageLib  load  imageData- gt path          a simplified manager class Manager      std  vector lt std  shared ptr lt ImageData gt  gt  m imageDatas     std  vector lt std  unique ptr lt std  thread gt  gt  m threads  public     void load  const std  string amp  folderPath           std  vector lt std  string gt  imagePaths   readFolder  folderPath          m imageDatas   createImageDatas  imagePaths          const unsigned numThreads   std  thread  hardware concurrency          std  vector lt std  vector lt std  shared ptr lt ImageData gt  gt  gt  splitDatas            splitImageDatas  m imageDatas  numThreads          for  auto amp  dataRangeToLoad   splitDatas           m threads push back  std  make unique lt std  thread gt  read  dataRangeToLoad               But it becomes much more complicated  if you want to interrupt the loading of the images  e g  because the user has chosen a different directory  Or even if you want to destroy the manager   You d need thread communication and have to stop all loader threads  before you may change your m imageDatas field  Otherwise the loaders would carry on loading until all images are done - even if they are already obsolete  In the simplified example  that wouldn t be too hard  but in a real environment things can be much more complicated    The threads would probably be part of a thread pool used by multiple managers  of which some are being stopped  and some aren t etc  The simple parameter imagesToLoad would be a locked queue  into which those managers push their image requests from different control threads with the readers popping the requests - in an arbitrary order - at the other end  And so the communication becomes difficult  slow and error-prone  A very elegant way to avoid any additional communication in such cases is to use std  shared ptr in conjunction with std  weak ptr      a simplified reader fn void read  std  vector lt std  weak ptr lt ImageData gt  gt  imagesToLoad        for  auto amp  imageDataWeak   imagesToLoad          std  shared ptr lt ImageData gt  imageData   imageDataWeak lock         if   imageData           continue       imageData- gt image   YourFavoriteImageLib  load  imageData- gt path               a simplified manager class Manager      std  vector lt std  shared ptr lt ImageData gt  gt  m imageDatas     std  vector lt std  unique ptr lt std  thread gt  gt  m threads  public     void load  const std  string amp  folderPath           std  vector lt std  string gt  imagePaths   readFolder  folderPath          m imageDatas   createImageDatas  imagePaths          const unsigned numThreads   std  thread  hardware concurrency          std  vector lt std  vector lt std  weak ptr lt ImageData gt  gt  gt  splitDatas            splitImageDatasToWeak  m imageDatas  numThreads          for  auto amp  dataRangeToLoad   splitDatas           m threads push back  std  make unique lt std  thread gt  read  dataRangeToLoad               This implementation is nearly as easy as the first one  doesn t need any additional thread communication  and could be part of a thread pool queue in a real implementation  Since the expired images are skipped  and non-expired images are processed  the threads never would have to be stopped during normal operation  You could always safely change the path or destroy your managers  since the reader fn checks  if the owning pointer isn t expired

User · Answer

std  weak ptr is a very good way to solve the dangling pointer problem  By just using raw pointers it is impossible to know if the referenced data has been deallocated or not  Instead  by letting a std  shared ptr manage the data  and supplying std  weak ptr to users of the data  the users can check validity of the data by calling expired   or lock     You could not do this with std  shared ptr alone  because all std  shared ptr instances share the ownership of the data which is not removed before all instances of std  shared ptr are removed  Here is an example of how to check for dangling pointer using lock      include  lt iostream gt   include  lt memory gt   int main            OLD  problem with dangling pointer        PROBLEM  ref will point to undefined data       int  ptr   new int 10       int  ref   ptr      delete ptr          NEW        SOLUTION  check expired   or lock   to determine if pointer is valid         empty definition     std  shared ptr lt int gt  sptr          takes ownership of pointer     sptr reset new int        sptr   10          get pointer to data without taking ownership     std  weak ptr lt int gt  weak1   sptr          deletes managed object  acquires new pointer     sptr reset new int        sptr   5          get pointer to new data without taking ownership     std  weak ptr lt int gt  weak2   sptr          weak1 is expired      if auto tmp   weak1 lock            std  cout  lt  lt   tmp  lt  lt    n       else         std  cout  lt  lt   weak1 is expired n           weak2 points to new data  5      if auto tmp   weak2 lock            std  cout  lt  lt   tmp  lt  lt    n       else         std  cout  lt  lt   weak2 is expired n

User · Answer

Here s one example  given to me by  jleahy  Suppose you have a collection of tasks  executed asynchronously  and managed by an std  shared ptr lt Task gt   You may want to do something with those tasks periodically  so a timer event may traverse a std  vector lt std  weak ptr lt Task gt  gt  and give the tasks something to do  However  simultaneously a task may have concurrently decided that it is no longer needed and die  The timer can thus check whether the task is still alive by making a shared pointer from the weak pointer and using that shared pointer  provided it isn t null

User · Answer

shared ptr   holds the real object   weak ptr    uses lock to connect to the real owner or returns a NULL shared ptr otherwise     Roughly speaking  weak ptr role is similar to the role of housing agency   Without agents  to get a house on rent we may have to check random houses in the city  The agents make sure that we visit only those houses which are still accessible and available for rent

User · Answer

http   en cppreference com w cpp memory weak ptr std  weak ptr is a smart pointer that holds a non-owning   weak   reference to an object that is managed by std  shared ptr  It must be converted to std  shared ptr in order to access the referenced object   std  weak ptr models temporary ownership  when an object needs to be accessed only if it exists  and it may be deleted at any time by someone else  std  weak ptr is used to track the object  and it is converted to std  shared ptr to assume temporary ownership  If the original std  shared ptr is destroyed at this time  the object s lifetime is extended until the temporary std  shared ptr is destroyed as well   In addition  std  weak ptr is used to break circular references of std  shared ptr

User · Answer

They are useful with Boost Asio when you are not guaranteed that a target object still exists when an asynchronous handler is invoked  The trick is to bind a weak ptr into the asynchonous handler object  using std  bind or lambda captures   void MyClass  startTimer         std  weak ptr lt MyClass gt  weak   shared from this        timer  async wait   weak  const boost  system  error code amp  ec                auto self   weak lock            if  self                        self- gt handleTimeout                      else                       std  cout  lt  lt   Target object no longer exists  n                          This is a variant of the self   shared from this   idiom often seen in Boost Asio examples  where a pending asynchronous handler will not prolong the lifetime of the target object  yet is still safe if the target object is deleted

User · Answer

weak ptr is also good to check the correct deletion of an object - especially in unit tests  Typical use case might look like this   std  weak ptr lt X gt  weak x  shared x    shared x reset    BOOST CHECK weak x lock           do something that should remove all other copies of shared x and hence destroy x BOOST CHECK  weak x lock

User · Answer

I see std  weak ptr lt T gt  as a handle to a std  shared ptr lt T gt   It allows me to get the std  shared ptr lt T gt  if it still exists  but it will not extend its lifetime  There are several scenarios when such point of view is useful      Some sort of image  very expensive to create  std  shared ptr lt  Texture  gt  texture      A Widget should be able to quickly get a handle to a Texture  On the    other hand  I don t want to keep Textures around just because a widget    may need it   struct Widget       std  weak ptr lt  Texture  gt  texture handle      void render             if  auto texture   texture handle get    texture                   do stuff with texture  Warning   texture                 is now extending the lifetime because it                is a std  shared ptr lt  Texture  gt             else                  gracefully degrade  there s no texture                       Another important scenario is to break cycles in data structures      Asking for trouble because a node owns the next node  and the next node owns    the previous node  memory leak  no destructors automatically called  struct Node       std  shared ptr lt  Node  gt  next      std  shared ptr lt  Node  gt  prev         Asking for trouble because a parent owns its children and children own their    parents  memory leak  no destructors automatically called  struct Node       std  shared ptr lt  Node  gt  parent      std  shared ptr lt  Node  gt  left child      std  shared ptr lt  Node  gt  right child         Better  break dependencies using a std  weak ptr  but not best way to do it     see Herb Sutter s talk   struct Node       std  shared ptr lt  Node  gt  next      std  weak ptr lt  Node  gt  prev         Better  break dependencies using a std  weak ptr  but not best way to do it     see Herb Sutter s talk   struct Node       std  weak ptr lt  Node  gt  parent      std  shared ptr lt  Node  gt  left child      std  shared ptr lt  Node  gt  right child       Herb Sutter has an excellent talk that explains the best use of language features  in this case smart pointers  to ensure Leak Freedom by Default  meaning  everything clicks in place by construction  you can hardly screw it up   It is a must watch

[c++11] When is std::weak_ptr useful?

Examples related to c++11

Examples related to shared-ptr

Examples related to weak-ptr

Examples related to c++-faq