{"id":108173,"date":"2023-05-10T07:00:00","date_gmt":"2023-05-10T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=108173"},"modified":"2023-05-10T08:48:55","modified_gmt":"2023-05-10T15:48:55","slug":"20230510-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20230510-00\/?p=108173","title":{"rendered":"What are the duck-typing requirements of ATL CComPtr<\/CODE>?"},"content":{"rendered":"

We continue our survey of duck-typing requirements of various C++ COM smart pointer libraries by looking at ATL’s CComPtr<\/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 <atlbase.h><\/span>\r\n#include <atlcom.h>\u00a0<\/span>\r\n\u00a0\r\nusing TestPtr = CComPtr<Test>;\u00a0\u00a0<\/span>\r\nusing OtherPtr = CComPtr<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.p<\/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.p<\/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
A glitch in the core functionality tests happens when we call ptr3.Attach(p)<\/code>:<\/p>\n
atlcomcli.h(250,1): error C2440: 'initializing': cannot convert from 'void' to 'ULONG'\r\n<\/pre>\n
The problem is here:<\/p>\n
    \/\/ Attach to an existing interface (does not AddRef)\r\n    void Attach(_In_opt_ T* p2) throw()\r\n    {\r\n        if (p)\r\n        {\r\n            ULONG ref = p->Release();\r\n            (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            ATLASSERT(ref != 0 || p2 != p);\r\n        }\r\n        p = p2;\r\n    }\r\n<\/pre>\n
ATL expects the Release<\/code> method to return a ULONG<\/code> representing the new reference count. So let’s fix our class to do that.<\/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<\/pre>\n
Okay, that gets us past the Attach<\/code>\/Detach<\/code> test.<\/p>\n
There are two ways to receive a new pointer. You can use the &<\/code> operator directly on the CComPtr<\/code>, which asserts that the smart pointer is already empty. If the pointer is an in\/out parameter, then you can take the address of the public p<\/code> member directly, which avoids the assertion check. There is no combined method for “release previous pointer before receiving a new one”.<\/p>\n
The comparison tests work as expected. They just compare the wrapped pointers.<\/p>\n
The accidental bypass litmus test and the test for accessing the wrapped object via the -><\/code> operator are interesting because CComPtr<\/code> uses a techique that author Jim Springfield called “coloring”:<\/p>\n
template <class T>\r\nclass _NoAddRefReleaseOnCComPtr :\r\n    public T\r\n{\r\n    private:\r\n        STDMETHOD_(ULONG, AddRef)()=0;\r\n        STDMETHOD_(ULONG, Release)()=0;\r\n};\r\n\r\ntemplate <class T>\r\nclass CComPtrBase\r\n{\r\n    ...\r\n\r\n    _NoAddRefReleaseOnCComPtr<T>* operator->() const throw()\r\n    {\r\n        ATLASSERT(p!=NULL);\r\n        return (_NoAddRefReleaseOnCComPtr<T>*)p;\r\n    }\r\n\r\n    ...\r\n};\r\n<\/pre>\n
The trick here is that instead of returning the wrapped T*<\/code> directly, we pretend that it is a pointer to the T<\/code> portion of a _NoAddRefReleaseOnCComPtr<T><\/code>, and return a pointer to that derived class. The _NoAddRefReleaseOnCComPtr<T><\/code> class declares the AddRef<\/code> and Release<\/code> as private, thereby making them inaccessible from the resulting -><\/code> operator:<\/p>\n
ptr->Release(); \/\/ error: Cannot call private method\u00b9\r\n<\/pre>\n
In the case where T<\/code> derives from IUnknown<\/code>, these virtual AddRef<\/code> and Release<\/code> methods override the same-signature methods in IUnknown<\/code>. But in the case where T<\/code> does not derive from IUnknown<\/code>, this adds a vtable to _NoAddRefReleaseOnCComPtr<\/code>. Now, this vtable is never materialized, but it nevertheless introduces some pointer arithmetic that the compiler cannot immediately optimize away, because  a static_cast<\/code> is not always just a pointer adjustment<\/a>.<\/p>\n
; ideally\r\nCComPtr<Test>::operator->()\r\n    lea     rax, [rcx-8]\r\n    ret\r\n\r\n; actually\r\nCComPtr<Test>::operator->()\r\n    lea     rdx, [rcx-8]\r\n    neg     rcx\r\n    sbb     rax, rax\r\n    and     rax, rdx\r\n    ret\r\n<\/pre>\n
The extra nonsense is there so that the cast from (T*)<\/code> to (_NoAddRefReleaseOnCComPtr<T>*)<\/code> produces nullptr<\/code> when passed nullptr<\/code>. (The “ideal” version would return -8<\/code>.)<\/p>\n
I call this a missed optimization because when the compiler inlines the -><\/code> operator, it can see that the resulting pointer is immediately dereferenced, so it cannot be null. Furthermore, the +8<\/code> that comes afterward to convert the (_NoAddRefReleaseOnCComPtr<T>*)<\/code> back to a (T*)<\/code> exactly cancels out the -8<\/code>, so all the pointer nonsense can be optimized out entirely. Bonusly furthermore, this<\/code> can never be nullptr<\/code>; invoking a method on a null pointer is undefined behavior.<\/p>\n
    ; ptr2->AddressOf()\r\n    ; ideally\r\n\r\n    mov     rcx, [ptr2].p\r\n    call    Test::AddressOf\r\n\r\n    ; actually\r\n    mov     rcx, [ptr2].p\r\n    mov     eax, 8\r\n    test    rcx, rcx\r\n    cmove   rcx, rax\r\n    call    Test::AddressOf\r\n<\/pre>\n
All of these problems could have been avoided if _NoAddRefReleaseOnCComPtr<\/code> had declared the private AddRef<\/code> and Release<\/code> as non-virtual.<\/p>\n
template <class T>\r\nclass _NoAddRefReleaseOnCComPtr :\r\n    public T\r\n{\r\n    private:\r\n        ULONG AddRef();\r\n        ULONG Release();\r\n};\r\n<\/pre>\n
This still accomplishes the task of making the AddRef<\/code> and Release<\/code> methods inaccessible, but it doesn’t introduce a vtable, which means that the static_cast<\/code> operations do not result in any code generation.<\/p>\n
But it’s too late to fix that now. That would be a binary breaking change.<\/p>\n
Other consequences of “coloring” are that the wrapped class T<\/code> cannot be final<\/code>, and if the T::AddRef<\/code> and T::Release<\/code> methods are virtual, they must return ULONG<\/code> and use STDMETHODCALLTYPE<\/code>.<\/p>\n
The CComPtr<\/code> passes the other litmus tests: Most of the operations generate an error complaining that the types do not match. The interesting one is the last one, the assignment of an other-type smart pointer.<\/p>\n
    template <typename Q>\r\n    T* operator=(_Inout_ const CComPtr<Q>& lp) throw()\r\n    {\r\n        if(!this->IsEqualObject(lp) )\r\n        {\r\n            AtlComQIPtrAssign2((IUnknown**)&this->p, lp, __uuidof(T));\r\n        }\r\n        return *this;\r\n    }\r\n<\/pre>\n
This one fails because the code uses CComPtrBase::IsEqualObject<\/code>, which in turn does not compile due to lack of Query\u00adInterface<\/code> support. Which is a good thing, because there is a C-style cast to IUnknown**<\/code> in the call to AtlComQIPtrAssign2<\/code>, which requires that our underlying type T<\/code> derive from IUnknown<\/code>.<\/p>\n
Okay, so here’s the scorecard for CComPtr<\/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
CComPtr<\/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>\np<\/code>, or implicit conversion<\/td>\n<\/tr>\n
Access the wrapped object<\/td>\n-><\/code> (suboptimal)<\/td>\n<\/tr>\n
Receive pointer via &<\/code><\/td>\nmust be empty<\/td>\n<\/tr>\n
Release and receive pointer<\/td>\n&<\/code><\/td>\n<\/tr>\n
Preserve and receive pointer<\/td>\n&p<\/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>\nPass<\/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> may not be final<\/code>.
\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
Netx time, we’ll look at WRL’s ComPtr<\/code>.<\/p>\n
\u00b9 Though you can hack around this by forcing a call to the base class version, or just using the raw wrapped pointer.<\/p>\n
\/\/ sneaky! ducking under the ribbon!\r\nptr->Test::Release();\r\nptr.p->Release();\r\n<\/pre>\n
The purpose of the “coloring” is not be be bulletproof. It’s just to prevent you from calling AddRef<\/code> and Release<\/code> by mistake.<\/p>\n","protected":false},"excerpt":{"rendered":"
Looking for the minimum requirements.<\/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-108173","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
Looking for the minimum requirements.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/108173","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=108173"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/108173\/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=108173"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=108173"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=108173"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}