shared_ptr uses an extra "counter" object (aka. "shared count" or "control block") to store the reference count.
(BTW: that "counter" object also stores the deleter.)
Every shared_ptr and weak_ptr contains a pointer to the actual pointee, and a second pointer to the "counter" object.
To implement weak_ptr, the "counter" object stores two different counters:
- The "use count" is the number of
shared_ptr instances pointing to the object.
- The "weak count" is the number of
weak_ptr instances pointing to the object, plus one if the "use count" is still > 0.
The pointee is deleted when the "use count" reaches zero.
The "counter" helper object is deleted when the "weak count" reaches zero (which means the "use count" must also be zero, see above).
When you try to obtain a shared_ptr from a weak_ptr, the library atomically checks the "use count", and if it's > 0 increments it. If that succeeds you get your shared_ptr. If the "use count" was already zero you get an empty shared_ptr instance instead.
EDIT: Now, why do they add one to the weak count instead of just releasing the "counter" object when both counts drop to zero? Good question.
The alternative would be to delete the "counter" object when both the "use count" and the "weak count" drop to zero. Here's the first reason: Checking two (pointer sized) counters atomically is not possible on every platform, and even where it is, it's more complicated than checking just one counter.
Another reason is that the deleter must stay valid until it has finished executing. Since the deleter is stored in the "counter" object, that means the "counter" object must stay valid. Consider what could happen if there is one shared_ptr and one weak_ptr to some object, and they are reset at the same time in concurrent threads. Let's say the shared_ptr comes first. It decreases the "use count" to zero, and begins executing the deleter. Now the weak_ptr decreases the "weak count" to zero, and finds the "use count" is zero as well. So it deletes the "counter" object, and with it the deleter. While the deleter is still running.
Of course there would be different ways to assure that the "counter" object stays alive, but I think increasing the "weak count" by one is a very elegant and intuitive solution. The "weak count" becomes the reference count for the "counter" object. And since shared_ptrs reference the counter object too, they too have to increment the "weak count".
A probably even more intuitive solution would be to increment the "weak count" for every single shared_ptr, since every single shared_ptr hold's a reference to the "counter" object.
Adding one for all shared_ptr instances is just an optimization (saves one atomic increment/decrement when copying/assigning shared_ptr instances).
