C++/WinRT deferred destruction and safe QI during destruction

[kennykerr]

Xaml apps can get themselves into knots because they need to perform a QI in a destructor to call some cleanup implementation up or down the hierarchy. This call involves a QI after the object's reference count has already reached zero. This update adds support for debouncing the reference count, ensuring that once it reaches zero it can never be resurrected but still allows QI for temporaries required during destruction. This all seems rather messy but is unavoidable in certain Xaml apps/controls and C++/WinRT should be resilient to this. The downside of debouncing is that it makes AddRef and Release a bit more expensive. The up side is that C++/WinRT is hardened and far more resilient to such abuses.

Destruction may be deferred by providing a static final_release function and moving ownership of the unique_ptr to some other context.

struct Sample : implements<Sample, IStringable>
{
    hstring ToString()
    {
        return L"Sample";
    }

    ~Sample()
    {
        // Called when the unique_ptr below is reset.
    }

    static void final_release(std::unique_ptr<Sample> ptr) noexcept
    {
        // Move 'ptr' as needed to delay destruction.
    }
};

In the example below once the MainPage is released (for the final time), final_release is called, which spends 5s waiting (on the thread pool) then resumes using the page’s Dispatcher (which requires QI/AddRef/Release to work). It then clears the unique_ptr, which causes the MainPage destructor to actually get called. Even here DataContext is called, which requires a QI for IFrameworkElement.

Obviously you don’t have to implement your final_release as a coroutine but that does work and makes it very simple to move destruction to a different thread.

struct MainPage : PageT<MainPage>
{
    MainPage()
    {
    }

    ~MainPage()
    {
        DataContext(nullptr);
    }

    static IAsyncAction final_release(std::unique_ptr<MainPage> ptr)
    {
        co_await 5s;

        co_await resume_foreground(ptr->Dispatcher());

        ptr = nullptr;
    }
};

[Scottj1s]

[DefaultRyan]

Some test cases involving IWeakReferenceSource and IWeakReference would be more valuable than IStringable.

[kennykerr]

Well IStringable proves that QI et al works, but agreed that adding test for IWeakReferenceSource is important to show that Resolve does not work. 😉