{"id":108177,"date":"2023-05-11T07:00:00","date_gmt":"2023-05-11T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=108177"},"modified":"2023-05-11T06:28:33","modified_gmt":"2023-05-11T13:28:33","slug":"20230511-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20230511-00\/?p=108177","title":{"rendered":"What are the duck-typing requirements of WRL ComPtr<\/CODE>?"},"content":{"rendered":"

We continue our survey of duck-typing requirements of various C++ COM smart pointer libraries by looking at WRL’s ComPtr<\/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 <wrl\/client.h><\/span>\r\n\u00a0\r\nusing TestPtr = Microsoft::WRL::ComPtr<Test>;\u00a0\u00a0<\/span>\r\nusing OtherPtr = Microsoft::WRL::ComPtr<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.Detach();\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.Get()<\/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 = nullptr;\r\n\r\n    \/\/ Receiving a new pointer\r\n    \/\/ (this changes based on library)\r\n    Test** out = &ptr3<\/span>;\r\n    out = ptr3.ReleaseAndGetAddressOf()<\/span>;\r\n    out = ptr3.GetAddressOf()<\/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
We encounter the same glitch as we did with ATL CComPtr<\/code>, but this time it happens twice. First, it happens at construction of the WRL ComPtr<\/code>:<\/p>\n
client.h(235,1): error C2440: '=': cannot convert from 'void' to 'unsigned long'\r\n<\/pre>\n
Due to this code:<\/p>\n
    unsigned long InternalRelease() throw()\r\n    {\r\n        unsigned long ref = 0;\r\n        T* temp = ptr_;\r\n\r\n        if (temp != nullptr)\r\n        {\r\n            ptr_ = nullptr;\r\n            ref = temp->Release();\r\n        }\r\n\r\n        return ref;\r\n    }\r\n<\/pre>\n
WRL wants to propagate the return value of Release<\/code>, and it expects the method to return an unsigned long<\/code>.<\/p>\n
The other failure occurs in a familiar place: On the Attach<\/code>.<\/p>\n
client.h(22,1): error C3313: 'ref': variable cannot have the type 'void'\r\n<\/pre>\n
The problem is here:<\/p>\n
    void Attach(_In_opt_ InterfaceType* other) throw()\r\n    {\r\n        if (ptr_ != nullptr)\r\n        {\r\n            auto ref = ptr_->Release();\r\n            (void)ref;\r\n            \/\/ Attaching to the same object only works if duplicate\r\n            \/\/ references are being coalesced.  Otherwise\r\n            \/\/ re-attaching will cause the pointer to be released and\r\n            \/\/ may cause a crash on a subsequent dereference.\r\n            __WRL_ASSERT__(ref != 0 || ptr_ != other);\r\n        }\r\n\r\n        ptr_ = other;\r\n    }\r\n<\/pre>\n
It’s clear that the WRL code derived from the ATL code, seeing as this is pretty much identical to the ATL code, down to the comments.<\/p>\n
So we have to fix our class in the same way we fixed it for ATL: Make the Release<\/code> method return a ULONG<\/code> representing the new reference count.<\/p>\n
struct Test\r\n{\r\n    void AddRef() { }\r\n    \/\/ Dummy implementation for testing purposes only.\r\n    ULONG Release() { return 1; }\r\n};\r\n\r\nstruct Other\r\n{\r\n    void AddRef() { }\r\n    \/\/ Dummy implementation for testing purposes only.\r\n    ULONG Release() { return 1; }\r\n};\r\n<\/pre>\n
Once we fix that up, the basic tests all pass. The comparison tests compare the wrapped pointers.<\/p>\n
There are three ways to receive a pointer in WRL. You can use the &<\/code> operator, which is a shorthand for the method call ReleaseAndGetAddressOf()<\/code>, which releases the old pointer and nulls it out, then returns the address of the pointer so a new value can be placed there. Alternatively, you can use GetAddressOf()<\/code>, which does not release the old pointer. Use GetAddressOf()<\/code> in the cases where the parameter is used as an in\/out pointer.<\/p>\n
WRL does not use the ATL trick of “coloring” the return value of the -><\/code> operator, so it does not have the ATL requirements that the wrapped class T<\/code> be non-final, or that the T::AddRef<\/code> and T::Release<\/code> methods must have the same signature and calling convention as IUnknown<\/code> if they are virtual.<\/p>\n
On the other hand, the lack of “coloring” means that you can accidentally write<\/p>\n
ptr2->Release();\r\n<\/pre>\n
instead of ptr2.Reset()<\/code>. WRL tries to make the problem less likely to occur by using a different name (Reset<\/code>) to try to reduce the chance of confusion.<\/p>\n
The other-type litmus tests all pass. They all result in various types of compile-time errors.<\/p>\n
Okay, so here’s the scorecard for ComPtr<\/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\n
ComPtr<\/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>\nGet()<\/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>\nReleaseAndGetAddressOf()<\/code><\/td>\n<\/tr>\n
Preserve and receive pointer<\/td>\nGetAddressOf()<\/code><\/td>\n<\/tr>\n
Return to empty state<\/td>\nPass<\/td>\n<\/tr>\n
Comparison<\/td>\nPass<\/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
Notes:
\nT<\/code> must have a method of the form ULONG Release()<\/code>.
\nThe T::Release<\/code> method must return nonzero if the object is still alive.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Our next smart pointer library will be com_ptr<\/code>.<\/p>\n","protected":false},"excerpt":{"rendered":"
Another round of experimentation.<\/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-108177","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
Another round of experimentation.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/108177","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=108177"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/108177\/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=108177"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=108177"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=108177"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}