{"id":108602,"date":"2023-08-15T07:00:00","date_gmt":"2023-08-15T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=108602"},"modified":"2023-08-15T07:38:17","modified_gmt":"2023-08-15T14:38:17","slug":"20230815-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20230815-00\/?p=108602","title":{"rendered":"Inside STL: The shared_ptr<\/CODE> constructor vs make_shared<\/CODE>"},"content":{"rendered":"

There are two ways to create a new object that is controlled by a shared_ptr<\/code>.<\/p>\n

\/\/ From a raw pointer\r\nauto p = std::shared_ptr<S>(new S());\r\n\r\n\/\/ Via make_shared\r\nauto p = std::make_shared<S>();\r\n<\/pre>\n
They result in two different memory layouts.<\/p>\n
In the first case, you manually created a new S<\/code> object, and then passed a pointer to it to the shared_ptr<\/code> constructor. The shared_ptr<\/code> adopts the raw pointer and creates a control block to monitor its lifetime. When the last shared pointer destructs, the Dispose()<\/code> method deletes the pointer you passed in.\u00b9 When the last shared or weak pointer destructs, the Delete()<\/code> method deletes the control block.<\/p>\n\n\n\n\n\n
p<\/td>\n <\/td>\n <\/td>\n<\/tr>\n
object<\/td>\n\u2022<\/td>\n\u2192<\/td>\n\n
S<\/div>\n<\/td>\n
freed separately<\/td>\n<\/tr>\n
control<\/td>\n\u2022<\/td>\n\u2192<\/td>\n\n
control_block<\/div>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
In the second case, you let the make_shared<\/code> function create the S<\/code> object, and in practice, what it does is create a single memory allocation that consists of a control block stacked on top of an S<\/code> object. This time, when the last shared pointer destructs, the Dispose()<\/code> method runs the S<\/code> destructor, but the memory isn’t freed yet. Only when the last shared or weak pointer destructs does the Delete()<\/code> method get called to free the entire memory block.<\/p>\n\n\n\n\n\n\n\n
p<\/td>\n <\/td>\n <\/td>\n <\/td>\n<\/tr>\n
object<\/td>\n\u2022<\/td>\n\u00a0<\/td>\ncontrol_block<\/td>\nfreed as a unit<\/td>\n<\/tr>\n
\u292e<\/td>\n<\/tr>\n
control<\/td>\n\u2022<\/td>\nS<\/td>\n<\/tr>\n
\u00a0<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
The two memory layouts have their own pros and cons.<\/p>\n\n\n\n\n\n\n\n
\u00a0<\/th>\nTwo allocations<\/th>\nSingle allocation<\/th>\n<\/tr>\n
Last shared
\npointer destructs<\/td>\n		Object destructs
\nObject memory freed<\/td>\n		Object destructs
\nObject memory not freed<\/td>\n<\/tr>\n
Last shared or weak
\npointer destructs<\/td>\n		Control block destructs
\nControl block freed<\/td>\n		Control block destructs
\nCombo block freed<\/td>\n<\/tr>\n
Locality<\/td>\nWorse<\/td>\nBetter<\/td>\n<\/tr>\n
Straggler weak pointer<\/td>\nControl block lingers
\n(Object memory freed already)<\/td>\n		Entire combo block lingers<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
The single-allocation version has better memory locality since the control block is kept right next to the managed object.<\/p>\n
On the other hand, with the single-allocation version, a straggler weak pointer (a weak pointer which lives for a long time after the last shared pointer has destructed) prevents the entire combo memory block from being freed. By comparison, only the control block remains in memory with the two-allocation version.<\/p>\n
If your weak pointers exist to break circular references, then you won’t have stragglers because they will go away when the object graph destructs. Similarly, if your weak pointers are in event handlers, then those weak pointers won’t be stragglers if you are careful to unregister the event handlers at destruction. The stragglers come into play if you retain weak references in, say, a cache or other long-lifetime storage, and even then, they cause a problem only if sizeof(S)<\/code> is significant or if you have a lot of them.<\/p>\n
Next time, we’ll look at make_shared<\/code>‘s close friend, std::enable_shared_from_this<\/code>.<\/p>\n
\u00b9 More specifically, the Deleter<\/code> object deletes the pointer you passed in. The default deleter uses the delete<\/code> operator to delete the pointer.<\/p>\n","protected":false},"excerpt":{"rendered":"
Where to hide the control block.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-108602","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing"],"acf":[],"blog_post_summary":"
Where to hide the control block.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/108602","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=108602"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/108602\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=108602"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=108602"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=108602"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}