转载地址

These modern C++ constructs express relationships among classes more intelligibly than raw pointers.
Tutorial | Jul 5, 2020 | unique_ptr, shared_ptr, weak_ptr, or reference_wrapper for class relationships - 图1
c++ shared-ptr weak-ptr unique-ptr reference smart-pointer c++11

1. Overview

Classes in C++ can be related through inheritance, by having instance members, or by having referring members (e.g., pointers) to other types.
In this article, we ignore the inheritance and refer to other relationships as associations. Here, we will explore how the Modern-C++ constructs, namely — unique_ptr, shared_ptr, weak_ptr, and reference_wrapper — can be used to create associations between classes with clearer purposes.

2. It’s about ownership

Classes communicate with each other by having handles as members that refer to other classes. The choice of those referring-handles (e.g., pointers or references) is mostly driven by ownership or control-over-lifetime semantics.
Before the Modern-C++, programmers had only references (&) and raw pointers to form the associations between classes. References are safe and they sufficiently represent the reference semantics, but they are too restrictive. References are hard to deal with as class members because they make an enclosing class non-assignable and immovable. For that reason, plain references are often avoided as class members. Raw pointers, on the other hand, are highly flexible catchalls but error-prone. Moreover, raw pointers are severely inadequate means to express all the intents.
Associations between classes can be seen through the viewpoint of ownership. An object can solely own another object, or it can share the ownership of an object with others, or it does not own but only refers to an object. The following sections show more appropriate means to express those associations than the raw pointers.

2.1. Sole ownership

sole / sEul; NAmE soul / ◙ adj. [only before noun]

  1. only; single

• 仅有的；唯一的:

»the sole surviving member of the family

那一家唯一在世的成员

»My sole reason for coming here was to see you.

我到这儿唯一的原因就是来看你。

»This is the sole means of access to the building.

这是这栋建筑物唯一的入口。

  1. belonging to one person or group; not shared

• 独占的；专有的；全权处理的:

»She has sole responsibility for the project.

那个项目由她一人负责。

»the sole owner

拥有全部产权的物主

A class can directly own another class’s instance as a member variable if the intention is to have sole ownership or composition. However, there are situations where a member should be created dynamically — for instance, when the member is polymorphic多态 or it needs to be released when not needed. In those cases, we can use a unique_ptr to control the uniquely owned object. Besides, it is also possible to transfer the exclusive ownership by moving a unique_ptr:

  1. /*Polymorphic parser hierarchy*/
  2. struct Parser {
  3.  //...
  4. };
  5. struct SpecialParserA : Parser {
  6.  //...
  7. };
  8. struct SpecialParserB : Parser {
  9.  //...
  10. };
  11. struct Protocol {
  12.  //....
  13.  Protocol(int parserType /*, more args */) {
  14.   //create a Parser depending on the args
  15.   if(parserType == 1)
  16.    parser = std::make_unique<SpecialParserA>();
  17.   else 
  18.    parser = std::make_unique<SpecialParserB>();
  19.   //...
  20.  }
  21.  std::unique_ptr<Parser> parser;
  22. };

Needless to say that a unique_ptr is better than a raw pointer for safer resource management and capturing the sole-ownership intent. Raw pointers do not establish the unique ownership themselves. A class that uses raw pointers for unique ownership must explicitly implement the move-construction/assignment and disallow copy-construction/assignment — that is too much of boilerplate code.

2.2. Shared ownership

In those situations where a class needs to share the ownership of an instance with other classes, the correct approach is to have a shared_ptr member. Multiple classes can share ownership of an object through many instances of shared_ptr. The owned object is guaranteed to stay alive as long as there is at least one shared_ptr holding it.
In the following example, multiple Sender objects share the ownership of a Connection object:

unique_ptr, shared_ptr, weak_ptr, or reference_wrapper for class relationships - 图2

  1. struct Connection {
  2.  //...
  3. };
  4. struct Sender {
  5.  std::shared_ptr<Connection> connection;
  6. };

Achieving shared ownership through raw pointers often ends up in reinvention of the wheel.

2.3. Weak shared ownership

Sometimes a class needs to share ownership, but it should not have firm control over the lifetime of the owned object. In those cases, a weak ownership handle is required that can convert to a strong handle on-demand. That weak handle in Modern-C++ is weak_ptr.
A weak_ptr represents a weak form of shared ownership. A weak_ptr can convert to a shared_ptr on-demand. The conversion to shared_ptr successfully happens if there is at least one shared_ptr still holding the managed object.
In the following example, a custom object cache keeps a weak_ptr to each cached item. By doing so, the cache does not ordinarily control an item’s lifetime but creates and returns a shared_ptr to it when requested by multiple clients. This way, an item stays in memory for only as long as it is in use by the clients:

unique_ptr, shared_ptr, weak_ptr, or reference_wrapper for class relationships - 图3

  1. struct Item {
  2.  //...
  3. };
  4. struct Cache {
  5.  auto getItem(int id) {
  6.   std::shared_ptr<Item> ret; 
  7.   //Search entry in the map
  8.   auto itr = itemsById.find(id);   
  9.   if(itr != itemsById.end()) {
  10.    //Found entry in the map
  11.    //Try to acquire a shared_ptr<Item> from weak_ptr<Item>
  12.    ret = itr->second.lock();
  13.   }
  14.   if(!ret) {
  15.    /*Either item is expired or entry is not found in the map.
  16.      Load fresh item from DB, initialize a shared_ptr, 
  17.        and insert a weak_ptr in the map*/
  18.    ret = std::make_shared<Item>(); //Initialize a shared_ptr     
  19.    itemsById[id] = ret; //Insert a weak_ptr in the map
  20.   }
  21.   //Return the shared_ptr<Item>   
  22.   return ret;
  23.  }
  24.  std::map<int, std::weak_ptr<Item>> itemsById; //Cache entries map
  25. };
  26. struct Client {
  27.  //...
  28.  //The item is acquired from Cache
  29.  std::shared_ptr<Item> item;
  30. };

2.4. No ownership

If a class merely refers or uses but does not control an object’s life, it does not own that object. In classic OOP, it is known as the Using relationship. Strictly going by the design, a reference (&) class member should be ideal for expressing this relation. But in practice, this relation is implemented with raw pointers because references are too restrictive. References cannot rebind, and a class holding a reference member becomes non-assignable and non-movable.
However, the problem with raw pointers is that they are too general and require excessive explicit validation. Raw pointers do not appropriately reflect reference semantics. Modern C++ offers a middle-ground solution for that in the form of std::reference_wrapper.
A reference_wrapper is a copyable and assignable object that wraps a pointer (T*) but imitates a reference (T&). A reference_wrapper can rebind to another object if required.
A reference_wrapper can be stored in an STL container also. For instance, in the following code, a class maintains a vector of reference_wrapper to observers:

  1. struct Observer {
  2.  //...
  3.  void notify();
  4. };
  5. struct Observed {
  6.  //...
  7.  void action() {
  8.   //notify all observers
  9.   for(auto& ob : observers)
  10.    ob.get().notify();
  11.  }
  12.  std::vector<std::reference_wrapper<Observer>> observers;
  13. };

A reference_wrapper cannot be null; it must refer to a valid object. This feature could be limiting in some cases that require nullable references. But if you are using C++17, you don’t have to resort to using raw pointers yet. C++17 provides std::optional that can wrap a reference_wrapper to model a nullable reference:

  1. struct Db {
  2.  void persist(const std::string& s); 
  3. };
  4. struct Processor {
  5.  //...
  6.  void process(const std::string& s) {
  7.   //processes data and then optionally saves to DB
  8.   if(dbRef) { //Check if reference is not null
  9.    //save data to DB 
  10.    dbRef->get().persist(s);
  11.   }
  12.  }
  13.  std::optional<std::reference_wrapper<Db>> dbRef;
  14. };

3. Conclusion

Associations among classes can be perceived through the ownership. Modern-C++ offers various means for classes to refer to each other with different semantics, which should be preferred over the raw pointers.

4. Further Reading

std::ref and std::reference_wrapper: common use cases - nextptr
Using weak_ptr for circular references - nextptr
shared_ptr - basics and internals with examples - nextptr