A control block of a shared_ptr
is kept alive while there is at least one weak_ptr
present. If the shared pointer was created with make_shared
that implies that the whole memory of the object is kept allocated. (The object itself is properly destructed, but since the control block and the memory for the object were allocated in one chunk, as make_shared
does, they can only be deallocated together.)
Is my understanding correct?
It seems that this behaviour represents a problem, for example in the famous "cache example". The memory for the objects will be kept allocated forever.
It it a problem in any practical situations? Shall the shared_ptr
be created using a constructor in such a situation (large object and intent to use weak_ptr
s)?
Is my understanding correct?
Yes. If your weak_ptr
s significantly outlive the (large) object and you are tight on memory, it may be beneficial to avoid make_shared
.
However, "large" here is measured by sizeof
, and many conceptually "large" objects (for example, most standard containers, except std::array
) are quite small by that metric, because they allocate additional memory to store their contents, which will be freed as soon as the object is destroyed.
I tried this in VS2013 and you're completely correct. The destructor is called when the last shared_ptr is destroyed, so any other objects or memory associated with the object will be destroyed, but if the shared_ptr is created with make_shared the memory is never destroyed until the last weak_ptr is.
I think it's always good to clean up or reset your weak_ptrs if lock() fails because even without make_shared it's still using some memory.