{"id":15953,"date":"2009-11-20T07:00:00","date_gmt":"2009-11-20T07:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/2009\/11\/20\/the-difference-between-assignment-and-attachment-with-atl-smart-pointers\/"},"modified":"2009-11-20T07:00:00","modified_gmt":"2009-11-20T07:00:00","slug":"the-difference-between-assignment-and-attachment-with-atl-smart-pointers","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20091120-00\/?p=15953","title":{"rendered":"The difference between assignment and attachment with ATL smart pointers"},"content":{"rendered":"

\nLast time,\n\nI presented a puzzle regarding a memory leak<\/a>.\nHere’s the relevant code fragment:\n<\/p>\n

\nCComPtr<IStream> pMemoryStream;<\/font>\nCComPtr<IXmlReader> pReader;\nUINT nDepth = 0;\n\/\/Open read-only input stream\npMemoryStream = ::SHCreateMemStream(utf8Xml, cbUtf8Xml);<\/font>\n<\/pre>\n
\nThe problem here is assigning the return value of\nSHCreateMemStream<\/code> to a smart pointer\ninstead of attaching it.\n<\/p>\n
\nThe SHCreateMemStream<\/code> function creates a memory stream\nand returns a pointer to it.\nThat pointer has a reference count of one,\nin accordance with COM rules that a function\n\nwhich produces a reference calls AddRef<\/code>,\nand the responsibility is placed upon the recipient\nto call Release<\/code><\/a>.\nThe assignment operator for CComPtr<T><\/code> is a copy operation:\nIt AddRef<\/code>s the pointer and saves it.\nYou’re still on the hook for the reference count of the original pointer.\n<\/p>\n
\nATLINLINE ATLAPI_(IUnknown*) AtlComPtrAssign(IUnknown** pp, IUnknown* lp)\n{\n        if (lp != NULL)\n                lp->AddRef();\n        if (*pp)\n                (*pp)->Release();\n        *pp = lp;\n        return lp;\n}\ntemplate <class T>\nclass CComPtr\n{\npublic:\n        ...\n        T* operator=(T* lp)\n        {\n                return (T*)AtlComPtrAssign((IUnknown**)&p, lp);\n        }\n<\/pre>\n
\nObserve that assigning a T*<\/code> to a CComPtr<T><\/code>\n\nAddRef<\/code>s the incoming pointer<\/a>\nand\nRelease<\/code>s the old pointer (if any).\nWhen the CComPtr<T><\/code> is destructed, it will release\nthe pointer, undoing the AddRef<\/code> that was performed by\nthe assignment operator.\nIn other words, assignment followed by destruction has a net effect\nof zero on the pointer you assigned.\nThe operation behaves like a copy.\n<\/p>\n
\nAnother way of putting a pointer into a CComPtr<T><\/code>\nis with the Attach<\/code> operator.\nThis is a transfer operation:\n<\/p>\n
\n        void Attach(T* p2)\n        {\n                if (p)\n                        p->Release();\n                p = p2;\n        }\n<\/pre>\n
\nObserve that there is no AddRef<\/code> here.\nWhen the CComPtr<T><\/code> is destructed,\nit will perform the Release<\/code>,\nwhich doesn’t undo any operation performed by the Attach<\/code>.\nInstead, it releases the reference count held by the original pointer\nyou attached.\n<\/p>\n
\nLet’s put this in a table, since people seem to like tables:\n<\/p>\n\n\n\n\n
Operation<\/th>\nBehavior<\/th>\nSemantics<\/th>\n<\/tr>\n
Attach()<\/td>\nTakes ownership<\/td>\nTransfer semantics<\/td>\n<\/tr>\n
operator=()<\/td>\nCreates a new reference<\/td>\nCopy semantics<\/td>\n<\/tr>\n<\/table>\n
\nYou use the Attach<\/code> method when you want to assume\nresponsibility for releasing the pointer (ownership transfer).\nYou use the assignment operator when you want the original pointer\nto continue to be responsible for its own release (no ownership transfer).\n<\/p>\n
\nThere is also a Detach<\/code> method which is the opposite of\nAttach<\/code>:\nDetaching a pointer from the CComPtr<T><\/code>\nmeans “I am taking over responsibility for releasing this pointer.”\nThe CComPtr<T><\/code> gives you its pointer and then forgets\nabout it; you’re now on your own.\n<\/p>\n
\nThe memory leak in the code fragment above occurs because the\nassignment operator has copy semantics, but we wanted transfer\nsemantics,\nsince we want the smart pointer to take the responsibility for\nreleasing the pointer when it is destructed.\n<\/p>\n
\npMemoryStream.Attach(::SHCreateMemStream(utf8Xml, cbUtf8Xml));\n<\/pre>\n
\nThe CComPtr<T>::operator=(T*)<\/code> method\nis definitely one of the more dangerous methods in the\nCComPtr<T><\/code> repertoire,\nbecause it’s so easy to assign a pointer to a smart pointer\nwithout giving it a moment’s thought.\n(Another dangerous method is the\nT** CComPtr<T>::operator&()<\/code>,\nbut at least that has an assertion to try to catch the bad usages.\nEven nastier is\n\nthe secret QI’ing assignment operator<\/a>.)\nI have to say that there is merit to\n\nBen Hutchings’ recommendation<\/a> simply not to allow a simple pointer\nto be assigned to a smart pointer, precisely because the semantics are\neasily misunderstood.\n(The boost library, for example, follows Ben’s recommendation.)\n<\/p>\n
\nHere’s another exercise based on what you’ve learned:\n<\/p>\n
\n
\nApplication Verifier told us that we have a memory leak,\nand we traced it back to the\nfunction GetTextAsInteger<\/code>.\n<\/p>\n
\nBSTR GetInnerText(IXMLDOMNode *node)\n{\n    BSTR bstrText = NULL;\n    node->get_text(&bstrText);\n    return bstrText;\n}\nDWORD GetTextAsInteger(IXMLDOMNode *node)\n{\n    DWORD value = 0;\n    CComVariant innerText = GetInnerText(node);\n    hr = VariantChangeType(&innerText, &innerText, 0, VT_UI4);\n    if (SUCCEEDED(hr))\n    {\n        value = V_UI4(&innerText);\n    }\n    return value;\n}\n<\/pre>\n
\nObviously, the problem is that we passed the same input and output\npointers to VariantChangeType<\/code>,\ncausing the output integer to overwrite the input BSTR<\/code>,\nresulting in the leak of the BSTR<\/code>.\nBut when we fixed the function, we still got the leak:\n<\/p>\n
\nDWORD GetTextAsInteger(IXMLDOMNode *node)\n{\n    DWORD value = 0;\n    CComVariant innerText = GetInnerText(node);\n    CComVariant textAsValue;<\/font>\n    hr = VariantChangeType(&innerText, &textAsValue<\/font>, 0, VT_UI4);\n    if (SUCCEEDED(hr))\n    {\n        value = V_UI4(&textAsValue<\/font>);\n    }\n    return value;\n}\n<\/pre>\n
\nIs there a leak in the VariantChangeType<\/code> function itself?\n<\/p>\n<\/blockquote>\n
\nHint: It is in fact explicitly documented that the output parameter\nto VariantChangeType<\/code> can be equal to the input parameter,\nwhich results in an in-place conversion.\nThere was nothing wrong with the original call to\nVariantChangeType<\/code>.<\/p>\n","protected":false},"excerpt":{"rendered":"
Last time, I presented a puzzle regarding a memory leak. Here’s the relevant code fragment: CComPtr<IStream> pMemoryStream; CComPtr<IXmlReader> pReader; UINT nDepth = 0; \/\/Open read-only input stream pMemoryStream = ::SHCreateMemStream(utf8Xml, cbUtf8Xml); The problem here is assigning the return value of SHCreateMemStream to a smart pointer instead of attaching it. The SHCreateMemStream function creates a memory […]<\/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":[25],"class_list":["post-15953","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
Last time, I presented a puzzle regarding a memory leak. Here’s the relevant code fragment: CComPtr<IStream> pMemoryStream; CComPtr<IXmlReader> pReader; UINT nDepth = 0; \/\/Open read-only input stream pMemoryStream = ::SHCreateMemStream(utf8Xml, cbUtf8Xml); The problem here is assigning the return value of SHCreateMemStream to a smart pointer instead of attaching it. The SHCreateMemStream function creates a memory […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/15953","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=15953"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/15953\/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=15953"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=15953"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=15953"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}