{"id":106381,"date":"2022-03-24T07:00:00","date_gmt":"2022-03-24T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=106381"},"modified":"2022-03-24T07:03:39","modified_gmt":"2022-03-24T14:03:39","slug":"20220324-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20220324-00\/?p=106381","title":{"rendered":"Behind C++\/WinRT: How does C++\/WinRT decide which interfaces are implemented?"},"content":{"rendered":"

Last time, we diagnosed a problem<\/a> by realizing that the unkwn.h<\/code> header had not been included prior<\/i> to including any C++\/WinRT headers, and that means that C++\/WinRT did not activate its code that supports classic COM interfaces.<\/p>\n

This is going to be the first in what will probably be a very sporadic series of looking into the C++\/WinRT implementation, as reverse-engineered by me.\u00b9 I’m writing it in part so that I’ll be able to refer back to this write-up the next time I have to debug this code. And in part so that there are more people who understand the insides of C++\/WinRT and can help support it. (This is the selfish reason for many of the articles I write: I’m writing them in order to reduce my own workload.)<\/p>\n

It all hangs on this definition of is_interface<\/code><\/a>:<\/p>\n

#ifdef WINRT_IMPL_IUNKNOWN_DEFINED\r\n\r\ntemplate <typename T>\r\nstruct is_interface : std::disjunction<\r\n    std::is_base_of<Windows::Foundation::IInspectable, T>,\r\n    std::conjunction<\r\n        std::is_base_of<::IUnknown, T>,\r\n        std::negation<is_implements<T>>>> {};\r\n\r\n#else\r\n\r\ntemplate <typename T>\r\nstruct is_interface :\r\n    std::is_base_of<Windows::Foundation::IInspectable, T> {};\r\n\r\n#endif\r\n<\/pre>\n
The WINRT_IMPL_IUNKNOWN_DEFINED<\/code> macro is an internal C++\/WinRT macro that remembers whether unknwn.h<\/code> has been included. If so, then ::IUnknown<\/code> is defined, and C++\/WinRT can activate classic COM support. Let’s translate the C++ type traits template meta-programming into something we’re more familiar with.<\/p>\n
One of the main tools of the C++ type traits system is the std::integral_constant<T, v><\/code>. This is a type that wraps a constant value v<\/code> of type T<\/code>.<\/p>\n
template<typename T, T v>\r\nstruct integral_constant\r\n{\r\n    static constexpr T value = v;\r\n    ... other stuff not relevant here ...\r\n};\r\n<\/pre>\n
For example, std::integral_constant<int, 42>::value<\/code> is an integer constant whose value is 42.<\/p>\n
This seems pointless, but it’s not. Template meta-programming doesn’t have variables; it operates on types. The std::integral_constant<\/code> lets you treat a type as if it were a variable whose value is the integral_constant::value<\/code>.<\/p>\n
C++ comes with a number of pre-made integral constants. Relevant today are std::true_type<\/code> and std::false_type<\/code>, which wrap a Boolean true<\/code> or false<\/code>, respectively. And it also comes with some pre-made template types that manipulate them:<\/p>\n
    \n
  • std::conjunction<\/code> performs a logical and<\/code> on its arguments.\u00b2<\/li>\n
  • std::disjunction<\/code> performs a logical or<\/code> on its arguments.<\/li>\n
  • std::negation<\/code> performs a logical not<\/code> on its argument.<\/li>\n<\/ul>\n
    Okay, now we can start taking apart the first expression.<\/p>\n
    template <typename T>\r\nstruct is_interface : std::disjunction<\r\n    std::is_base_of<Windows::Foundation::IInspectable, T>,\r\n    std::conjunction<\r\n        std::is_base_of<::IUnknown, T>,\r\n        std::negation<is_implements<T>>>> {};\r\n<\/pre>\n
    We mentally convert the std::disjunction<\/code> to ||<\/code>, the std::conjunction<\/code> to &&<\/code>, and the std::negation<\/code> to !<\/code>.<\/p>\n
    template <typename T>\r\nstruct is_interface is true if\r\n    std::is_base_of<Windows::Foundation::IInspectable, T> ||\r\n    (\r\n        std::is_base_of<::IUnknown, T> &&\r\n        !is_implements<T>);\r\n<\/pre>\n
    Now we can read out the logic. Something is considered an interface if either<\/p>\n
      \n
    • It derives from winrt::Windows::Foundation::IInspectable<\/code>, or<\/li>\n
    • It derives from ::IUnknown<\/code> and is not an implements<\/code>.<\/li>\n<\/ul>\n
      The rejection of implements<\/code> prevents is_interface<\/code> from misdetecting implements<\/code> as a itself being COM interface.<\/p>\n
      Onward to the #else<\/code>: If unknwn.h<\/code> was not included, then we use a simpler definition of is_interface<\/code> that merely detects derivation from winrt::Windows::Foundation::IInspectable<\/code>.<\/p>\n
      In order to detect classic COM interfaces, C++\/WinRT needs ::IUnknown<\/code> to have been defined. Otherwise, it has nothing to test as a base class.<\/p>\n
      So that’s the quick diagnosis of yesterday’s problem wherein C++\/WinRT failed to recognize classic COM interfaces.<\/p>\n
      Next time, we’ll dig in deeper to how the is_interface<\/code> definition is used to pick out the interfaces.<\/p>\n
      Bonus chatter<\/b>: As I noted last time, the requirement that you include unknwn.h<\/code> before including C++\/WinRT is no longer present as of C++\/WinRT version 2.0.210922.5. The trick is to forward-declare the ::IUnknown<\/code> type so that you can talk about it without knowing what it is. The std::is_base_class<\/code> template type requires only that the proposed derived class be complete. The base class (::IUnknown<\/code>) doesn’t have to be complete.<\/p>\n
      Exercise<\/b>: Why is it okay for std::is_base_class<\/code> to accept an incomplete base class? How can it possibly detect whether something derives from a class which has no definition?<\/p>\n
      \u00b9 A lot of learning comes from reverse-engineering. When doing debugging, you are pretty much forced into it.<\/p>\n
      \u00b2 Actually, std::conjunction<\/code> and std::disjunction<\/code> behave more like their JavaScript equivalent operators &&<\/code> and ||<\/code> because they short-circuit and support “truthiness”.<\/p>\n
      Answer to exercise<\/b>: If the base class is incomplete, then nothing can derive from it. You can’t derive from an incomplete type.<\/p>\n","protected":false},"excerpt":{"rendered":"
      Finding the code that does the interface detection.<\/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-106381","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
      Finding the code that does the interface detection.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/106381","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=106381"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/106381\/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=106381"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=106381"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=106381"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}