{"id":110895,"date":"2025-02-21T07:00:00","date_gmt":"2025-02-21T15:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=110895"},"modified":"2025-02-21T07:34:24","modified_gmt":"2025-02-21T15:34:24","slug":"20250221-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20250221-00\/?p=110895","title":{"rendered":"C++\/WinRT implementation inheritance: Notes on winrt::implements<\/CODE>, part 3"},"content":{"rendered":"

In C++\/WinRT, the implements<\/code> template type starts like this:<\/p>\n

template <typename D, typename... I>\r\nstruct implements :\r\n    impl::producers<D, I...>,\r\n    impl::base_implements<D, I...>::type\r\n{\r\n<\/pre>\n
The producers<\/code> template type generates the vtables for the COM interfaces. But that’s not what we’re looking at today. Today we’re going to look at the base_implements<\/code> part.<\/p>\n
The base_implements<\/code> type is defined as follows:<\/p>\n
template <typename D, typename Dummy = std::void_t<>, typename... I>\r\nstruct base_implements_impl\r\n    : impl::identity<root_implements<D, I...>> {};\r\n\r\ntemplate <typename D, typename... I>\r\nstruct base_implements_impl<D, std::void_t<typename nested_implements<I...>::type>, I...>\r\n    : nested_implements<I...> {};\r\n\r\ntemplate <typename D, typename... I>\r\nusing base_implements = base_implements_impl<D, void, I...>;\r\n<\/pre>\n
 We learned from last time that this uses  SFINAE<\/a>: to implement an “if then else” pattern. In this case, it’s saying “If nested_implements<I...>::type<\/code> exists, then derive from nested_implements<I...><\/code>. Otherwise, derive from impl::identity<root_implements<D, I...>><\/code>.”<\/p>\n
template <typename T>\r\nstruct identity\r\n{\r\n    using type = T;\r\n};\r\n<\/pre>\n
Okay, so identity<T>::type<\/code> is just T<\/code>. This is basically  a copy of std::type_identity<\/code><\/a>. C++\/WinRT supports C++17, but std::type_identity<\/code> didn’t show up until C++20, so C++\/WinRT provides its own copy.<\/p>\n
Applying this to base_implements_impl<\/code> simplifies it to “If nested_implements<I...>::type<\/code> exists, then derive from nested_implements<I...><\/code>. Otherwise, derive from root_implements<D, I...><\/code>.”<\/p>\n
So what is nested_implements<\/code>?<\/p>\n
template <typename...>\r\nstruct nested_implements\r\n{};\r\n\r\ntemplate <typename First, typename... Rest>\r\nstruct nested_implements<First, Rest...>\r\n    : std::conditional_t<is_implements_v<First>,\r\n    impl::identity<First>, nested_implements<Rest...>>\r\n{\r\n    static_assert(\r\n        !is_implements_v<First> ||\r\n        !std::disjunction_v<is_implements<Rest>...>,\r\n        \"Duplicate nested implements found\");\r\n};\r\n<\/pre>\n
This is a recursively-defined nested_implements<\/code>. In the base case, nested_implements<><\/code> is an empty class. Otherwise, we peel off the first template parameter and see if it derives from implements<\/code>. If so, then we use it. Otherwise, we recurse on the remaining parameters.<\/p>\n
So nested_implements<\/code> searches through the template parameters and takes the first one that derives from implements<\/code>. Otherwise, it’s an empty class.<\/p>\n
But wait, there’s extra work done in the static_assert<\/code>. First, let’s translate it from C++ template-ese to pseudo-code. The std::disjunction<\/code> takes the logical OR of its arguments, so the second part expands to !(is_implements_v<Rest1> || is_implements_v<Rest2> || ...)<\/tt>, which says “None of the Rest<\/code> is an implements<\/code>.”<\/p>\n
Now combine this with the first part, and we get “Either First<\/code> is not an implements<\/code>, or none of the Rest<\/code> is an implements<\/code>.” If you transform this to an implication relation, you get “If First<\/code> is an implements<\/code>, then none of the Rest<\/code> is an implements<\/code>.”<\/p>\n
During the recursion, First<\/code> progresses through all of the interface arguments, so the assertion verifies that at most one of the interface arguments supports implements<\/code>.<\/p>\n
Okay, so unwinding back to base_implements<\/code>, we had previously determined that the definition was “If nested_implements<I...>::type<\/code> exists, then derive from nested_implements<I...><\/code>. Otherwise, derive from impl::identity<root_implements<D, I...>><\/code>.” Combining this with our discovery that nested_implements<\/code> takes the first interface that is an implements<\/code>, we see that the result is that base_implements<\/code> is<\/p>\n
    \n
  • If none of the interfaces is an implements<\/code>, then use root_implements<\/code>.<\/li>\n
  • If exactly one of the interfaces is an implements<\/code>, then use it. (It will provide the root_implements<\/code> so we don’t have to.)<\/li>\n
  • If more than one of the interfaces is an implements<\/code>, then raise a compile-time error.<\/li>\n<\/ul>\n
    From all this, you can figure out the legal inheritance structures for winrt::implements<\/code>: The implements<\/code> must form a single chain of inheritance, possibly passing through other non-implements<\/code> classes along the way. You cannot inherit (directly or indirectly) from multiple implements<\/code>. The innermost implements<\/code> provides the root_implements<\/code>.<\/p>\n
    \u00a0<\/div>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
     <\/td>\n <\/td>\nA<\/td>\n <\/td>\n <\/td>\n <\/td>\nA : implements<A, I1, B, I2>, X1<\/tt><\/td>\n<\/tr>\n
     <\/td>\n <\/td>\n\u2193<\/td>\n\u2198<\/td>\n <\/td>\n <\/td>\n <\/td>\n<\/tr>\n
     <\/td>\n <\/td>\nimplements<\/tt><\/td>\n <\/td>\nX1<\/td>\n <\/td>\n <\/td>\n <\/td>\n<\/tr>\n
     <\/td>\n\u2199<\/td>\n\u2193<\/td>\n\u2198<\/td>\n <\/td>\n <\/td>\n <\/td>\n<\/tr>\n
    produce<A, I1><\/tt><\/td>\n <\/td>\nB<\/td>\n <\/td>\nproduce<A, I2><\/tt><\/td>\n <\/td>\nB : implements<B, C, I3><\/tt><\/td>\n<\/tr>\n
     <\/td>\n <\/td>\n\u2193<\/td>\n <\/td>\n <\/td>\n <\/td>\n <\/td>\n<\/tr>\n
     <\/td>\n <\/td>\nimplements<\/tt><\/td>\n <\/td>\n <\/td>\n <\/td>\n<\/tr>\n
     <\/td>\n <\/td>\n\u2193<\/td>\n\u2198<\/td>\n <\/td>\n <\/td>\n <\/td>\n<\/tr>\n
     <\/td>\n <\/td>\nC<\/td>\n <\/td>\nproduce<B, I3><\/tt><\/td>\n <\/td>\nC : D, X2<\/tt><\/td>\n<\/tr>\n
     <\/td>\n <\/td>\n\u2193<\/td>\n\u2198<\/td>\n <\/td>\n <\/td>\n <\/td>\n<\/tr>\n
     <\/td>\n <\/td>\nD<\/td>\n <\/td>\nX2<\/td>\n <\/td>\nD : implements<D, I4, I5><\/tt><\/td>\n<\/tr>\n
     <\/td>\n\u2199<\/td>\n\u2193<\/td>\n\u2198<\/td>\n <\/td>\n <\/td>\n <\/td>\n<\/tr>\n
    root_implements<\/tt><\/td>\n <\/td>\nproduce<D, I4><\/tt><\/td>\n <\/td>\nproduce<D, I5><\/tt><\/td>\n <\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
    Next time, we’ll look at how you can employ base classes and inheritance in your Windows Runtime implementation classes while still adhering to these restrictions.<\/p>\n
    \n