{"id":108161,"date":"2023-05-09T07:00:00","date_gmt":"2023-05-09T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=108161"},"modified":"2023-10-05T17:42:15","modified_gmt":"2023-10-06T00:42:15","slug":"20230509-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20230509-00\/?p=108161","title":{"rendered":"What are the duck-typing requirements of MFC IPTR<\/CODE>?"},"content":{"rendered":"

We continue our survey of duck-typing requirements of various C++ COM smart pointer libraries by looking at MFC’s IPTR<\/code>, running it through our standard tests.<\/p>\n

\/\/ Dummy implementations of AddRef and Release for\r\n\/\/ testing purposes only. In real code, they would\r\n\/\/ manage the object reference count.\r\nstruct Test\r\n{\r\n    void AddRef() {}\r\n    void Release() {}\r\n    Test* AddressOf() { return this; }\r\n};\r\n\r\nstruct Other\r\n{\r\n    void AddRef() {}\r\n    void Release() {}\r\n};\r\n\r\n\/\/ Pull in the smart pointer library\r\n\/\/ (this changes based on library)\r\n#include <afxole.h><\/span>\r\n\u00a0\r\nextern const GUID IID_Test;  <\/span>\r\nextern const GUID IID_Other; <\/span>\r\nusing TestPtr = IPTR(Test);  <\/span>\r\nusing OtherPtr = IPTR(Other);<\/span>\r\n\r\nvoid test()\r\n{\r\n    Test test;\r\n\r\n    \/\/ Default construction\r\n    TestPtr ptr;\r\n\r\n    \/\/ Construction from raw pointer\r\n    TestPtr ptr2(&test);\r\n\r\n    \/\/ Copy construction\r\n    TestPtr ptr3(ptr2);\r\n\r\n    \/\/ Attaching and detaching\r\n    auto p = ptr3.GetInterfacePtr();<\/span>\r\n    ptr3.Detach();\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<\/span>\r\n    ptr.Attach(p);\r\n\r\n    \/\/ Assignment from same-type raw pointer\r\n    ptr3 = &test;\r\n\r\n    \/\/ Assignment from same-type smart pointer\r\n    ptr3 = ptr;\r\n\r\n    \/\/ Accessing the wrapped object\r\n    \/\/ (this changes based on library)\r\n    if (ptr.GetInterfacePtr()<\/span> != &test) {\r\n        std::terminate(); \/\/ oops\r\n    }\r\n    if (ptr->AddressOf() != &test) {\r\n        std::terminate(); \/\/ oops\r\n    }\r\n\r\n    \/\/ Returning to empty state\r\n    ptr3.Release(); \/\/ requires ptr3 be non-empty<\/span>\r\n    ptr3 = static_cast<Test*><\/span>(nullptr);\r\n    ptr3.Attach(nullptr);<\/span>\r\n\r\n    \/\/ Receiving a new pointer\r\n    \/\/ (this changes based on library)\r\n    Test** out = &ptr3<\/span>;\r\n\r\n    \/\/ Bonus: Comparison.\r\n    if (ptr == ptr2) {}\r\n    if (ptr != ptr2) {}\r\n    if (ptr < ptr2) {}\r\n\r\n    \/\/ Litmus test: Accidentally bypassing the wrapper\r\n    ptr->AddRef();\r\n    ptr->Release();\r\n\r\n    \/\/ Litmus test: Construction from other-type raw pointer\r\n    Other other;\r\n    TestPtr ptr4(&other);\r\n\r\n    \/\/ Litmus test: Construction from other-type smart pointer\r\n    OtherPtr optr;\r\n    TestPtr ptr5(optr);\r\n\r\n    \/\/ Litmus test: Assignment from other-type raw pointer\r\n    ptr = &other;\r\n\r\n    \/\/ Litmus test: Assignment from other-type smart pointer\r\n    ptr = optr;\r\n\r\n    \/\/ Destruction\r\n}\r\n<\/pre>\n
The IPTR<\/code> macro assumes that the IID<\/code> that corresponds to the alleged interface is named IID_Blah<\/code>. We give it a dummy ID interface in the form of a reference to a variable that is never defined. This ensures a linker error if the code ever tries to use that fake interface ID.<\/p>\n
The IPTR.Detach<\/code> method does not return the detached pointer. You have to fetch it yourself via Get\u00adInterface\u00adPtr()<\/code> if you want to save it.<\/p>\n
Returning the smart pointer to an empty state can be done in multiple ways.<\/p>\n
    \n
  • The Release()<\/code> method releases the wrapped pointer, but there must be a non-null wrapped pointer in the first place. It is an error to call ptr3.Release()<\/code> on an empty ptr3<\/code>.<\/li>\n
  • You can use the assignment operator to assign a nullptr<\/code>. However, there are multiple assignment operators,\u00b9 so you have to cast the nullptr<\/code> to Test*<\/code> to say, “I am assigning a new pointer to be wrapped.”<\/li>\n
  • A sneaky way to avoid the extra typing is to use the Attach()<\/code> method to attach a null pointer. The first parameter to Attach()<\/code> is always a Test*<\/code>, so there is no ambiguity in passing just nullptr<\/code>.<\/li>\n<\/ul>\n
    The only way to receive a new pointer is to use the &<\/code> operator. This operator releases any previous wrapped pointer before receiving the new one.<\/p>\n
    The IPTR<\/code> fails the bonus comparison test, but not through any fault of the Test<\/code> class. The IPTR<\/code> simply doesn’t support comparison at all, not even for COM interfaces.<\/p>\n
    The IPTR<\/code> macro fails the “accidental bypass” litmus test, in the same way that _com_ptr_t<\/code> did. As with _com_ptr_t<\/code>, there are two ways of releasing the object that are dangerously similar:<\/p>\n
    ptr2.Release(); \/\/ good\r\nptr2->Release(); \/\/ bad\r\n<\/pre>\n
    The same cautions apply.<\/p>\n
    The IPTR<\/code> passes the other litmus tests: All of the attempts to convert or assign from another type of smart pointer or raw pointer generate errors.<\/p>\n
    Okay, so here’s the scorecard for IPTR<\/code>.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
    MFC IPTR<\/code> scorecard<\/th>\n<\/tr>\n
    Default construction<\/td>\nPass<\/td>\n<\/tr>\n
    Construct from raw pointer<\/td>\nPass<\/td>\n<\/tr>\n
    Copy construction<\/td>\nPass<\/td>\n<\/tr>\n
    Destruction<\/td>\nPass<\/td>\n<\/tr>\n
    Attach and detach<\/td>\nPass<\/td>\n<\/tr>\n
    Assign to same-type raw pointer<\/td>\nPass<\/td>\n<\/tr>\n
    Assign to same-type smart pointer<\/td>\nPass<\/td>\n<\/tr>\n
    Fetch the wrapped pointer<\/td>\nGetInterfacePtr()<\/code><\/td>\n<\/tr>\n
    Access the wrapped object<\/td>\n-><\/code><\/td>\n<\/tr>\n
    Receive pointer via &<\/code><\/td>\nrelease old<\/td>\n<\/tr>\n
    Release and receive pointer<\/td>\n&<\/code><\/td>\n<\/tr>\n
    Preserve and receive pointer<\/td>\nN\/A<\/td>\n<\/tr>\n
    Return to empty state<\/td>\nPass<\/td>\n<\/tr>\n
    Comparison<\/td>\nNot supported<\/td>\n<\/tr>\n
    Accidental bypass<\/td>\nFail<\/td>\n<\/tr>\n
    Construct from other-type raw pointer<\/td>\nPass<\/td>\n<\/tr>\n
    Construct from other-type smart pointer<\/td>\nPass<\/td>\n<\/tr>\n
    Assign from other-type raw pointer<\/td>\nPass<\/td>\n<\/tr>\n
    Assign from other-type smart pointer<\/td>\nPass<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
    Next time, we’ll look at ATL’s CComPtr<\/code>.<\/p>\n
    \u00b9 The other assignment operators accept CLSID<\/code> and PCWSTR<\/code> and create a new object identifed by the CLSID<\/code> or ProgId. Fortunately, it’s unlikely that you will assign one of these things to a a COM smart pointer by mistake.<\/p>\n","protected":false},"excerpt":{"rendered":"
    Seeing what goes wrong and trying to fix it.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-108161","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
    Seeing what goes wrong and trying to fix it.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/108161","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=108161"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/108161\/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=108161"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=108161"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=108161"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}