Why does shared_ptr needs to hold reference counting for weak_ptr?

Question

Quoted from C++ Primer $12.1.6:

A weak_ptr (Table 12.5) is a smart pointer that does not control the lifetime of the object to which it points. Instead, a weak_ptr points to an object that is managed by a shared_ptr. Binding a weak_ptr to a shared_ptr does not change the reference count of that shared_ptr. Once the last shared_ptr pointing to the object goes away, the object itself will be deleted. That object will be deleted even if there are weak_ptrs pointing to it—hence the name weak_ptr, which captures the idea that a weak_ptr shares its object “weakly.”

However,I've read an article says:

using make_shared is more efficient. The shared_ptr implementation has to maintain housekeeping information in a control block shared by all shared_ptrs and weak_ptrs referring to a given object. In particular, that housekeeping information has to include not just one but two reference counts:

A “strong reference” count to track the number of shared_ptrs currently keeping the object alive. The shared object is destroyed (and possibly deallocated) when the last strong reference goes away.

A “weak reference” count to track the number of weak_ptrs currently observing the object. The shared housekeeping control block is destroyed and deallocated (and the shared object is deallocated if it was not already) when the last weak reference goes away.

As far as I know,the shared_ptr created by make_shared is in the same control block with those ref countings.So the object will not be released until the last weak_ptr expires.

Question：

Is the Primer wrong? Because weak_ptr will actually affects the lifetime of that object.
Why does the shared_ptr need to track its weak refs?The weak_ptr can tell if the object exists by checking the strong refs in control blocks,so I think the control block does not need to track the weak refs.

Just for curiosity,what does the control block created by shared_ptr look like?Is it something like:

template<typename T>
class control_block
{
   T object;
   size_t strong_refs;
   size_t weak_refs;
   void incre();
   void decre();
   //other member functions...
};
//And in shared_ptr:
template<typename T>
class shared_ptr
{
   control_block<T> block;//Is it like this?So that the object and refs are in the same block?
   //member functions...
};

@juanchopanza That's why I'm confused,as quoted in the second paragraph,the object is in the control block,and it will not be released until last weak_ref expires. — scottxiao
There's two objects being managed here the pointed to object that is deleted when the last shared_ptr is removed and the control block object that contains the reference count that is deleted when the last managed pointer to it is deleted (including shared and weak ptrs) — PeterT
Destroyed and deallocated are separate events. And there is always a pointer, only 1 less allocation in case of make_shared. — rustyx
@bigxiao: to be more precise: delete ptr destroys the pointed to object by calling its destructor if it has any, which end the lifetime of the object and then calls operator delete(), which can be specific for the object type, that (by default) deallocates the heap memory that was allocated for the object. — Maarten Hilferink

BoBTFish BoBTFish · Accepted Answer · 2018-03-31T08:43:11

The reference count controls the lifetime of the pointed-to-object. The weak count does not, but does control (or participate in control of) the lifetime of the control block.

If the reference count goes to 0, the object is destroyed, but not necessarily deallocated. When the weak count goes to 0 (or when the reference count goes to 0, if there are no weak_ptrs when that happens), the control block is destroyed and deallocated, and the storage for the object is deallocated if it wasn't already.

The separation between destroying and deallocating the pointed-to-object is an implementation detail you don't need to care about, but it is caused by using make_shared.

If you do

shared_ptr<int> myPtr(new int{10});

you allocate the storage for the int, then pass that into the shared_ptr constructor, which allocates storage for the control block separately. In this case, the storage for the int can be deallocated as early as possible: as soon as the reference count hits 0, even if there is still a weak count.

If you do

auto myPtr = make_shared<int>(10);

then make_shared might perform an optimisation where it allocates the storage for the int and the control block in one go. This means that the storage for the int can't be deallocated until the storage for the control block can also be deallocated. The lifetime of the int ends when the reference count hits 0, but the storage for it is not deallocated until the weak count hits 0.

Is that clear now?

Why does shared_ptr needs to hold reference counting for weak_ptr?

Question：

4 Answers