The trick here is that the registration cookie is of type DWORD, which fits in a pointer, so we can smuggle the integer value inside a pointer.

template<typename T>
struct fake_agile_ref
{
private:
    using Smart = std::conditional_t<
        std::is_base_of_v<winrt::Windows::Foundation::IUnknown, T>,
        T, winrt::com_ptr<T>>;

    struct git_deleter                                                                           
    {                                                                                            
        winrt::com_ptr<IGlobalInterfaceTable> m_git;                                             
                                                                                                 
        void operator()(void* p)                                                                 
        {                                                                                        
            m_git->RevokeInterfaceFromGlobal(static_cast<DWORD>(reinterpret_cast<uintptr_t>(p)));
        }                                                                                        
    };                                                                                           

    winrt::com_ptr<IContextCallback> m_context;
    ULONG_PTR m_token = 0;
    std::unique_ptr<void, git_deleter> m_cookie;
    void* m_raw = nullptr;

Our custom deleter holds a pointer to the Global Interface Table and uses it to revoke the cookie on destruction. The cookie is an integer smuggled inside a pointer, so we cast the pointer back to an integer by passing through a uintptr_t to avoid a compiler warning about casting between an integer and pointer of different sizes.

We are relying on the fact that Windows implementations are required to support round-tripping integers through pointers. Macros like MAKEINTRESOURCE rely on it. It’s also codified in Windows with helper functions like PtrToInt and IntToPtr, but I’m writing it out for expository purposes rather than using those helpers.

We can then store the Global Interface Table pointer and the corresponding cookie in the unique_ptr:

    fake_agile_ref(Smart const& p) : m_raw(winrt::get_abi(p))
    {
        if (m_raw) {
            m_context = winrt::capture<IContextCallback>(CoGetObjectContext);
            m_token = get_context_token();
            auto& git = m_cookie.get_deleter().m_git;                                          
            git = winrt::create_instance<IGlobalInterfaceTable>(CLSID_StdGlobalInterfaceTable);
            DWORD cookie;                                                                      
            winrt::check_hresult(git->RegisterInterfaceInGlobal(
                winrt::make<force_marshal<Smart>>(p).get(),
                __uuidof(IUnknown), &m_cookie));
            m_cookie.reset(reinterpret_cast<void*>(static_cast<uintptr_t>(cookie)));
        }
    }

And now that we are letting unique_ptr manage the lifetime of the cookie, we don’t need a custom destructor, which allows us to use the Rule of Zero and simply not have any copy or move constructors or assignment operators.

    // fake_agile_ref(fake_agile_ref&& other) noexcept :
    //     m_context(std::move(other.m_context)),
    //     m_token(std:exchange(other.m_token, 0)),
    //     m_git(std::move(other.m_git)),
    //     m_cookie(std::exchange(other.m_cookie, 0)),
    //     m_raw(other.m_raw)
    // {
    // }

    // fake_agile_ref& operator=(fake_agile_ref&& other) noexcept
    // {
    //     using std::swap;
    //     swap(m_context, other.m_context);
    //     swap(m_token, other.m_token);
    //     swap(m_git, other.m_git);
    //     swap(m_cookie, other.m_cookie);
    //     swap(m_raw, other.m_raw);
    // }

    // ~fake_agile_ref()
    // {
    //     if (m_cookie) {
    //        m_git->RevokeInterfaceFromGlobal(std::exchange(m_cookie, 0));
    //    }
    // }

Since we are storing the cookie in a unique_ptr, we need to adjust the empty method:

    bool empty() const noexcept
    {
        return reinterpret_cast<uintptr_t>(m_cookie.get()) != 0;
    }

Bonus chatter: The Windows Implementation Library (wil) has a class similar to unique_ptr called wil::unique_any that lets you apply cleanup to any data type, not just a pointer.

The post Creating a fake agile wrapper that is technically agile but is not useful outside its home apartment, part 5 appeared first on The Old New Thing.

One thing we can do is move the non-marshalable COM object rather than copying it. This means forwarding the reference all the way into the force_marshal wrapper.

template<typename Smart>
struct force_marshal :
    winrt::implements<force_marshal<Smart>, IUnknown, winrt::non_agile>
{
    template<typename Arg>                                   
    force_marshal(Arg&& arg) : m_p(std::forward<Arg>(arg)) {}
    Smart m_p;
};

The force_marshal<Smart> now takes anything and forwards it into the smart pointer. This means that if the inbound parameter is an rvalue reference to a smart pointer, the COM reference is moved into the force_marshal<Smart> object rather than copied.

Now it’s a matter of plumbing this reference all the way down.

template<typename T>
struct fake_agile_ref
{
    ⟦ ... ⟧

    template<typename Arg>
    fake_agile_ref(Arg&& p) : m_raw(winrt::get_abi(p))
    {
        if (m_raw) {
            m_context = winrt::capture<IContextCallback>(CoGetObjectContext);
            m_token = get_context_token();
            m_git = winrt::create_instance<IGlobalInterfaceTable>(CLSID_StdGlobalInterfaceTable);
            winrt::check_hresult(m_git->RegisterInterfaceInGlobal(
                winrt::make<force_marshal<Smart>>(std::forward<Arg>(p)).get(),
                __uuidof(IUnknown), &m_cookie));
        }
    }

    ⟦ ... ⟧
};

template<typename Delegate>
std::remove_reference_t<Delegate> make_agile_delegate(Delegate&& d)
{
    if (d.try_as<::IAgileObject>()) {
        return d;
    }

    if (d.try_as<::INoMarshal>()) {
        return [agile = fake_agile_ref(std::forward<Delegate>(d)](auto&&...args) {
            return agile.get()(std::forward<decltype(args)>(args)...);
        };
    }

    return [agile = winrt::agile_ref(d)](auto&&...args) {
        return agile.get()(std::forward<decltype(args)>(args)...);
    };
}

Note that we didn’t have to update the deduction guides for fake_agile_ref to add forwarding support. Deduction guides are matched against the constructor invocation to determine which template specialization to use, but they are not used for actually invoking the constructor. That happens by matching against the constructors themselves. So if somebody tries to create a fake_agile_ref from an rvalue reference, the deduction guide for const& steers class template argument deduction (CTAD) toward the correct specialization, and then when the compiler actually looks for a constructor, it finds the one that takes an rvalue reference.

Remember how I complained that we couldn’t use std::unique_ptr to avoid a lot of boilerplate in fake_agile_ref to manage the fact that cookies cannot be copied?

Yeah, so maybe I lied.

We’ll look at it next time.

The post Creating a fake agile wrapper that is technically agile but is not useful outside its home apartment, part 4 appeared first on The Old New Thing.

So we will just force the square peg into the round hole: We can put the non-marshalable object inside an object that is marshalable.

template<typename Smart>
struct force_marshal :
    winrt::implements<force_marshal<Smart>, ::IUnknown, winrt::non_agile>
{
    force_marshal(Smart const& p) : m_p(p) {}
    Smart m_p;
};

The force_marshal<Smart> object babysits a non-marshalable smart pointer to a COM object and exposes a marshalable wrapper around it. Since the wrapped object is not agile, the wrapper cannot be either. (If the wrapper were agile, then we’d be back where we started: How do we ensure that the m_p is destructed in the correct apartment?)¹

We can put the unmarshalable object inside the wrapper, and then put the wrapper in the global interface table.

template<typename T>
struct fake_agile_ref
{
    ⟦ ... ⟧

    fake_agile_ref(Smart const& p) : m_raw(winrt::get_abi(p))
    {
        if (m_raw) {
            m_context = winrt::capture<IContextCallback>(CoGetObjectContext);
            m_token = get_context_token();
            m_git = winrt::create_instance<IGlobalInterfaceTable>(CLSID_StdGlobalInterfaceTable);
            winrt::check_hresult(m_git->RegisterInterfaceInGlobal(
                winrt::make<force_marshal<Smart>>(p).get(),
                __uuidof(IUnknown), &m_cookie));
        }
    }

    ⟦ ... ⟧
};

template<typename T> fake_agile_ref(winrt::com_ptr<T> const&)
    -> fake_agile_ref<T>;
template<typename T> fake_agile_ref(T const&)
    -> fake_agile_ref<T>;

Okay, so now we have managed to create an agile wrapper around an unmarshalable object. This agile wrapper is agile on paper: You can use it from any thread. However, it is not agile in practice: If you try to use it from the wrong apartment, it throws an exception. But at least the behavior when used from the wrong apartment is well-defined, as opposed to the case of directly using an unmarshalable object from the wrong apartment, which is undefined.

Next time, we’ll do some fine tuning.

Bonus chatter: Of course, now that we have a marshalable wrapper, we could use that wrapper to call the original non-marshalable object.

The non-marshalable object does not allow any arrows to come in from other apartments, but the wrapper lives in the same apartment as the non-marshalable object, so its arrow is coming from within the same apartment.

You can think of the wrapper as a VPN into the original apartment, allowing calls to come in from the outside, but to appear to the non-marshalable object as if they came from within the same apartment.

Now, you could do that, but I’m not going to. The original object presumably went out of its way to declare itself non-marshalable for a reason, so we honor that preference and not play funny games to trick it into doing something it said that it didn’t want to do.

¹ Two commenters fell into this trap by suggesting that we wrap the non-marshalable object inside an object that implements IMarshal. If you implement IMarshal, then you are saying, “I’m way cooler than a standard non-agile object. I’m going to do fancy stuff (like being agile).” But we want to be a boring non-agile object, so that COM will do standard marshaling for us.

The post Creating a fake agile wrapper that is technically agile but is not useful outside its home apartment, part 3 appeared first on The Old New Thing.

template<typename T>
struct fake_agile_ref
{
private:
    using Smart = std::conditional_t<
        std::is_base_of_v<winrt::Windows::Foundation::IUnknown, T>,
        T, winrt::com_ptr<T>>;

We define Smart to represent the smart pointer that holds a T. If T is a projected type, then it is already a smart pointer. Otherwise, T is a COM interface, and we put it inside a com_ptr. This is the same pattern that the C++/WinRT agile_ref<T> uses.

    winrt::com_ptr<IContextCallback> m_context;
    ULONG_PTR m_token = 0;
    winrt::com_ptr<IGlobalInterfaceTable> m_git;
    DWORD m_cookie = 0;
    void* m_raw = nullptr;

Our fake agile reference starts with a callback context and a context token. These are used to detect whether we are in the correct apartment when it comes time to access the original non-agile COM object.

Next comes a reference to the GIT and a cookie that records the registered reference to the original non-agile COM object.

Finally, we keep a raw (non-refcounted) pointer to the original non-agile COM object.

The fake agile reference is considered “empty” if the cookie is zero, meaning that it does not refer to any object. In the case of an empty fake agile reference, none of the other members contains anything meaningful.

public:
    fake_agile_ref(std::nullptr_t = nullptr) noexcept {}

Constructing an empty fake_agile_ref is easy: Just leave everything at its initial state. In particular, the m_cookie is zero, meaning that there is nothing inside. The values of all the other members are irrelevant, as long as they can be safely destructed.

    fake_agile_ref(Smart const& p) : m_raw(winrt::get_abi(p))
    {
        if (m_raw) {
            m_context = winrt::capture<IContextCallback>(CoGetObjectContext);
            m_token = get_context_token();
            m_git = winrt::create_instance<IGlobalInterfaceTable>(CLSID_StdGlobalInterfaceTable);
            winrt::check_hresult(m_git->RegisterInterfaceInGlobal(
                static_cast<::IUnknown*>(m_raw), __uuidof(IUnknown), &m_cookie));
        }
    }

To construct a fake_agile_ref from a smart pointer, we extract the raw pointer and check whether it is null. If so, then the smart pointer is empty, and we leave the m_cookie at zero. But if it is not null, we initialize the context information (so we can recognize this apartment later), and we register the COM object in the GIT to retain a reference to it for as long as the apartment is valid.

    fake_agile_ref(fake_agile_ref&& other) noexcept :
        m_context(std::move(other.m_context)),
        m_token(std:exchange(other.m_token, 0)),
        m_git(std::move(other.m_git)),
        m_cookie(std::exchange(other.m_cookie, 0)),
        m_raw(other.m_raw)
    {
    }

Since we will have a nontrivial destructor, we need copy and move constructors per the Rule of Five. The move constructor merely steals all the content from the source and leaves the source in the empty state. We don’t need to create a copy constructor because the move constructor causes the implicitly-defined copy constructor to become deleted. (The fake agile reference is not copyable because we don’t know how to copy the cookie.)

    fake_agile_ref& operator=(fake_agile_ref&& other) noexcept
    {
        using std::swap;
        swap(m_context, other.m_context);
        swap(m_token, other.m_token);
        swap(m_git, other.m_git);
        swap(m_cookie, other.m_cookie);
        swap(m_raw, other.m_raw);
    }

The fake agile reference also needs a move assignment operator to satisfy the Rule of Five. It just swaps the contents with the assigned-from object. Again, we don’t need a copy assignment operator because the declared move assignment operator causes the implicitly-defined copy assignment operator to become deleted.

    bool empty() const noexcept
    {
        return m_cookie == 0;
    }

    explicit operator bool() const noexcept
    {
        return !empty();
    }

An explicit boolean conversion operator lets callers test the fake agile pointer to see whether it is empty.

    ~fake_agile_ref()
    {
        if (!empty()) {
            m_git->RevokeInterfaceFromGlobal(std::exchange(m_cookie, 0));
        }
    }

We have reached our nontrivial destructor: If we have a GIT cookie, we revoke it. It would have been nice to let this be a custom deleter of a unique_ptr, but a cookie is not a pointer, and unique_ptr works only with pointers.

    [[nodiscard]] Smart get() const
    {
        if (empty()) {
            return nullptr;
        }
        if (m_token != get_context_token()) {
            throw winrt::hresult_error(CO_E_NOT_SUPPORTED);
        }

        Smart result{ nullptr };
        winrt::copy_from_abi(result, m_raw);
        return result;
    }

Here is where the excitement is. To recover the original COM object, we first check if the fake agile pointer is empty. If so, then there is no COM object to return. If the fake agile pointer is nonempty, but we are in the wrong apartment, then we throw the CO_E_NOT_SUPPORTED exception which is the same thing that Ro­Get­Agile­Reference does.

Otherwise, we are in the correct context. Our cookie is keeping the original object alive, so we can just recover it from the raw pointer. (We could also redeem the cookie from the GIT, but this is faster.)

};

That ends the definition of fake_agile_ref, but we’re not done yet.

template<typename T> fake_agile_ref(winrt::com_ptr<T> const&)
    -> fake_agile_ref<T>;
template<typename T> fake_agile_ref(T const&)
    -> fake_agile_ref<T>;

These deduction guides allow class template argument deduction (CTAD) to deduce the T from the constructor parameter: If the constructor parameter is a com_ptr<T>, then the template type parameter is T. Otherwise, the template type parameter matches the constructor parameter, which we assume is a projected type.

We can now use this fake agile reference as a drop-in replacement for the normal agile reference in the case that the delegate is not marshalable.

template<typename Delegate>
std::remove_reference_t<Delegate> make_agile_delegate(Delegate&& d)
{
    if (d.try_as<::IAgileObject>()) {
        return d;
    }

    if (d.try_as<::INoMarshal>()) {
        return [agile = fake_agile_ref(d)](auto&&...args) {
            return agile.get()(std::forward<decltype(args)>(args)...);
        };
    }

    return [agile = winrt::agile_ref(d)](auto&&...args) {
        return agile.get()(std::forward<decltype(args)>(args)...);
    };
}

Unfortunately, when we take this out for a spin and give it a non-marshalable delegate, it fails at this line:

            winrt::check_hresult(m_git->RegisterInterfaceInGlobal(
                static_cast<::IUnknown*>(m_raw), __uuidof(IUnknown), &m_cookie));

That’s because Register­Interface­In­Global will not register objects that deny marshalability.

Oh great, so we’re back to square one.

We’ll break the cycle of despair next time.

The post Creating a fake agile wrapper that is technically agile but is not useful outside its home apartment, part 2 appeared first on The Old New Thing.

What we want is something between a strong reference and a weak reference. We want a reference that is strong, but which releases its reference to the destination when the originating apartment tears down.

Is there such a thing?

It turns out that there is.

What we can do is register the object in the global interface table (historically known as the GIT, unrelated to the source control system). The usual reason for doing this is to allow the object to be accessed from another apartment by redeeming the registration cookie. We have no intention of accessing the object from another apartment, but we do this to take advantage of a feature of the GIT: References in the GIT are automatically released when the object’s apartment shuts down. The registration cookie remains valid, but if you try to redeem it, you are told that the server is no longer available.

So the idea here to register the original delegate in the GIT and save it in the agile wrapper. The agile wrapper then unregisters the delegate on destruction. We never redeem the registration cookie. The purpose of registering the delegate was not to access it from another apartment, but just to auto-release it when the original apartment tears down.

So let’s try it.

Next time.

The post Creating a fake agile wrapper that is technically agile but is not useful outside its home apartment, part 1 appeared first on The Old New Thing.

Let’s look at the first part: What if IContext­Callback::Context­Callback fails?

If it fails, it means that COM couldn’t switch to the destination context.

If you can’t switch to the destination context, then you can’t release the pointer. It’s not clear what recovery is possible anyway. Do you just keep retrying until it finally works?

If the destination context is an ASTA, then it’s possible that the reason is that the context is already busy, and ASTA doesn’t allow re-entrancy. We’d have to wait a little bit and try again later, when the destination context might be ready. We can’t just block on the retry because the destination context might be calling into the thread we are on right now, so just spinning in a retry loop won’t help because it’s waiting for us! We’re have to return, allow whatever we’re doing to finish, which in turn allows the ASTA to resume, and then it becomes worthwhile to try to call into the ASTA again.

This would be the issue for conventional COM calls into the ASTA, but we are using IContextCallback, and that lets us control whether or not to honor ASTA reentrancy roadblocks.

If riid is set to IID_ICallbackWithNoReentrancyToApplicationSTA, the function does not reenter an ASTA arbitrarily.

We are not passing that special value, so our call to Context­Callback is allowed to reenter an ASTA. That removes one possible source of failure.

What other reasons could there be for not being able to switch to the destination apartment?

The most likely reason is that the destination apartment no longer exists, in which case there is no recovery. Depending on how the object was managed by its creating thread, it might have been forcibly destroyed at thread termination¹, or it may simply have been leaked. We don’t know. At any rate, there’s no way to release it now.

The other case is that the destination apartment is not reachable due to a low-memory condition. We discussed earlier how the most common reason is a destination thread that has stopped responding to messages. I guess you could wait and try again later, but in practice if a thread has stopped responding for so long that its inbound message queue is full, the odds that it will magically start responding soon are pretty low.

All of the failures are effectively unrecoverable. But some of them are non-fatal, such as the Co­Disconnect­Object discussed in the footnote. Unfortunately, we can’t tell what case we are in. The Context­Callback returns RPC_E_DISCONNECTED to say that the destination apartment no longer exists, but we don’t know how that apartment cleaned up its orphaned objects.

The C++/CX implementation of lazy-created agile delegates ignores errors that occur trying to release the original pointer. So we’ll do the same.

But wait, we can do better. Next time.

¹ This is often combined with a Co­Disconnect­Object to tell proxies to fail all calls with RPC_E_DISCONNECTED, so that there are no external references to destroyed objects.

The post Making an agile version of a Windows Runtime delegate in C++/WinRT, part 10 appeared first on The Old New Thing.

I looked at the three major C++ implementations of the Windows Runtime: C++/WinRT, C++/CX, and WRL.

The C++/WinRT implementation has an optimization for IAgile­Object, but for objects that aren’t agile, it just goes directly to agile_ref without checking for INoMarshal. This means that a delegate that declares non-marshability will always be rejected by C++/WinRT when used as an event handler.

The C++/CX implementation lazy-creates the agile reference to the original delegate when the wrapper is used from a different apartment. If the original delegate is non-marshalable, it means that the CO_E_NOT­SUPPORTED is produced only when the wrapper is used in a way that requires a marshalable delegate.

The WRL implementation does not have an optimization for IAgile­Object, although it mentions it as a possible optimization. It always creates the agile reference eagerly, which means that if the original delegate is non-marshalable, it cannot be added to an agile event source.

Okay, so let’s summarize in a table.

Now, maybe you think we are working too hard. (Maybe we are.) In which case you can remove support for whatever cases you feel you don’t need.

The post Making an agile version of a Windows Runtime delegate in C++/WinRT, part 9 appeared first on The Old New Thing.

To recap, here is where we left off:

    if (d.try_as<::INoMarshal>()) {
        in_context_deleter del;
        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, std::move(del)),
            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);
                }
            };
    }

Precreating the deleter means that an exception in its construction happens before we do any funny business with the raw pointer. That way, we close the gap between creating the raw pointer (with its reference obligation) and putting it into a unique_ptr.

Or did we?

In C++, the order of construction of the captures of a lambda is unspecified.

[expr.prim.lambda.capture]

(10.2) ⟦ … ⟧ For each entity captured by copy, an unnamed non-static data member is declared in the closure type. The declaration order of these members is unspecified.

Since the order of construction is the order of declaration, the fact that the declaration order is unspecified implies that the order of construction is unspecified. And just to make sure you get the point, this is reiterated in paragraph 15 where it discusses the initialization of captures:

(15) ⟦ … ⟧ These initializations are performed when the lambda-expression is evaluated and in the (unspecified) order in which the non-static data members are declared.

Therefore, it’s possible that the get_context_token() happens before the creation of the std::unique_ptr, and if get_context_token() fails, then the reference held in the raw pointer is leaked because it never got put into a unique_ptr.

One solution is to put it into a unique_ptr before we create the lambda.

    if (d.try_as<::INoMarshal>()) {
        in_context_deleter del;
        void* p;
        if constexpr (std::is_reference_v<Delegate>) {
            p = winrt::detach_abi(d);
        } else {
            winrt::copy_to_abi(d, p);
        }
        std::unique_ptr<void, in_context_deleter> up(p, std::move(del));
        return
            [p = std::move(up),
            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);
                }
            };
    }

By creating the unique_ptr immediately, we remove any opportunity for an exception to sneak in between the time we create an obligation in the raw pointer and the time we assign that obligation to the unique_ptr.

One thing that bugs me about this is that we introduce another unique_ptr, which means that its destructor will have to check something for null, when it’s almost always null.

We can avoid this temporary unique_ptr by using copy elision directly into the capture.

    if (d.try_as<::INoMarshal>()) {
        auto make = [](auto&& d) {
            in_context_deleter del;
            void* p;
            if constexpr (std::is_reference_v<Delegate>) {
                p = winrt::detach_abi(d);
            } else {
                winrt::copy_to_abi(d, p);
            }
            return std::unique_ptr<void,                      
                       in_context_deleter>(p, std::move(del));
        };                                                    
        return
            [p = make(std::forward<Delegate>(d)),
            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);
                }
            };
    }

Bonus reading: Previously, in copy elision.

But an easier solution is to create the token early, just like we did with the deleter.

    if (d.try_as<::INoMarshal>()) {
        in_context_deleter del;
        auto token = get_context_token();
        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, std::move(del)),
             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);
                }
            };
    }

Okay, are we done?

Maybe.

But maybe this all wasn’t worth it.

We’ll talk about that next time.

The post Making an agile version of a Windows Runtime delegate in C++/WinRT, part 8 appeared first on The Old New Thing.

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 exception. We fixed it by constructing the deleter explicitly as a parameter, so that the unique_ptr constructor can move it into the stored deleter without an exception.

But wait, if an exception occurs in construction of the in_context_deleter, the raw pointer we created in the previous block will be leaked. It owns a reference count but doesn’t clean up in the case of an exception.

We can fix this by creating the deleter first.

    if (d.try_as<::INoMarshal>()) {
        in_context_deleter del;
        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, std::move(del)),
            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);
                }
            };
    }

If there is an exception constructing the custom deleter, it happens before we initialze the raw pointer, so there is no leak of the reference owned by that raw pointer.

Okay, so are we done now?

Nope.

More next time.

The post Making an agile version of a Windows Runtime delegate in C++/WinRT, part 7 appeared first on The Old New Thing.

But we missed something.

Again.

    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);
                }
            };
    }

The first part gets a raw ABI pointer, either by moving it out of the inbound delegate if we can, else by copying it from the inbound delegate. The reference count is owned by the raw pointer.

The second part wraps the raw ABI pointer inside a std::unique_ptr with our custom deleter. The unique pointer now owns the reference count, and the custom deleter will release it.

The problem is that one of the requirements for a custom deleter is that if you use the unique_ptr(p) constructor, the custom deleter must not throw an exception at construction.

[unique.ptr.single.ctor]

constexpr explicit unique_ptr(type_identity_t<pointer> p) noexcept;

Constraints: is_pointer_v<deleter_type> is false and is_default_constructible_v<deleter_type> is true.

Preconditions: D meets the Cpp17DefaultConstructible requirements, and that construction does not throw an exception.

But our custom deleter could throw an exception if Co­Get­Object­Context fails. So it doesn’t meet the preconditions.

We can fix that by using the constructor that takes an explicit deleter from which the stored deleter can be move-constructed. If an exception occurs, it happens during the creation of the parameter and not inside the unique_ptr constructor.

    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);
                }
            };
    }

Okay, so now we’re done?

Nope, still broken.

More next time.

The post Making an agile version of a Windows Runtime delegate in C++/WinRT, part 6 appeared first on The Old New Thing.