问题
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_ptrs)?
回答1:
Is my understanding correct?
Yes. If your weak_ptrs 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.
回答2:
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.
来源：https://stackoverflow.com/questions/32113594/weak-ptr-make-shared-and-memory-deallocation