Making an agile version of a Windows Runtime delegate in C++/WinRT, part 7

This article discusses the challenges of creating a unique_ptr with a deleter in C++/WinRT, particularly focusing on exception safety and memory management. It provides insights into handling exceptions during the construction of custom deleters to prevent memory leaks.

From the article

Last time, we fixed the problem of creating a unique_ptr whose deleter’s constructor was might throw an exception . But we’re not out of the woods yet.

Let’s take another look at what we have:

if (d.try_as<::INoMarshal>()) { void* p; if constexpr (std::is_reference_v<Delegate>) { p = winrt::detach_abi(d); } else { winrt::copy_to_abi(d, p); } return [p = std::unique_ptr<void, in_context_deleter>(p, {}), token = get_context_token()](auto&&...args) { if (token == get_context_token()) { std::remove_reference_t<Delegate> d; winrt::copy_from_abi(d, p.get()); d(std::forward<decltype(args)>(args)...); } else { throw winrt::hresult_error(CO_E_NOT_SUPPORTED); } }; } We had originally broken the rule that the unique_ptr(p) constructor requires that the deleter’s default constructor not throw an…

Share this resource