{"id":105838,"date":"2021-10-27T07:00:00","date_gmt":"2021-10-27T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=105838"},"modified":"2021-10-27T08:28:15","modified_gmt":"2021-10-27T15:28:15","slug":"20211027-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20211027-00\/?p=105838","title":{"rendered":"Giving a single object multiple COM identities, part 2"},"content":{"rendered":"

Last time, we looked at how you can give a single object multiple COM identities<\/a> so that different clients can maintain references to different parts of the object without knowing about the other parts.<\/p>\n

The idea here is that each identity is its own separate collection of IUnknown<\/code> interfaces which are interconnected via Query\u00adInterface<\/code> to each other, but all of the identities share the same AddRef<\/code> and Release<\/code>, so that the lifetime of the collective ends only when all the identities run down.<\/p>\n

Our previous implementation gave each embedded identity a pointer to the outer object so it could access the shared AddRef<\/code> and Release<\/code> methods, as well as forward any calls to the outer object for processing.<\/p>\n\n\n\n\n\n\n\n\n\n
\u00a0<\/td>\n\u00a0<\/td>\nprimary vtable<\/td>\n\u25c1<\/td>\n\u00a0<\/td>\n<\/tr>\n
\u00a0<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\nreference count<\/td>\n <\/td>\n\u00a0<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\nother data
\n\u22ee<\/td>\n		 <\/td>\n\u00a0<\/td>\n<\/tr>\n
CallbackWrapper<\/td>\n <\/td>\nembedded vtable<\/td>\n <\/td>\n\u00a0<\/td>\n<\/tr>\n
\u00a0<\/td>\n\u00a0<\/td>\nm_outer<\/code><\/td>\n <\/td>\n\u00a0<\/td>\n<\/tr>\n
\u00a0<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

But it turns out that this pointer is redundant: Recovering the outer object from the embedded object can be done from the embedded object’s this<\/code> pointer because the embedded object is at a fixed compile-time offset from the start of the outer object. All we have to do is adjust the embedded object’s this<\/code> pointer to get a pointer to the outer object.<\/p>\n

ULONG CallbackWrapper::AddRef()\r\n{\r\n    Outer* outer =  reinterpret_cast<Outer*>(\r\n        reinterpret_cast<uintptr_t>(this) - offsetof(Outer, m_wrapper));\r\n    return outer->AddRef();\r\n}\r\n<\/pre>\n
One major problem is that the CallbackWrapper<\/code> class doesn’t know what member name to use as the second parameter to the offsetof<\/code> macro. You could establish a convention that “Oh, the name must be m_wrapper<\/code>,” but that would prevent you from having more than one wrapper.<\/p>\n
Even if you knew the name of the member variable, you can’t calculate the offset of a member variable before the type is complete.<\/p>\n
struct Widget final : IWidget, ...\r\n{\r\n    ...\r\n    HRESULT OnCallback();\r\n    CallbackWrapper<&Widget::OnCallback> m_wrapper;\r\n    ...\r\n};\r\n<\/pre>\n
At the point Callback\u00adWrapper<;&Widget::OnCallback1><\/code> is instantiated, not only is the Widget<\/code> type incomplete, it doesn’t even have a member named m_wrapper<\/code> yet!<\/p>\n
But you know what you can do before a type is complete? You can static_cast<\/code> between the type and its base types. The compiler will do the work of calculating and applying the pointer adjustment (once it is known).<\/p>\n
So let’s try it:<\/p>\n
ULONG CallbackWrapper::AddRef()\r\n{\r\n    Outer* outer = static_cast<Outer*>(this);\r\n    return outer->AddRef();\r\n}\r\n\r\nstruct Widget final : IWidget, CallbackWrapper<&Widget::OnCallback>\r\n{\r\n    ...\r\n    HRESULT OnCallback();\r\n    ...\r\n};\r\n<\/pre>\n
This doesn’t work because we are now talking about Widget::OnCallback<\/code> before it has been declared. Unfortunately, you cannot forward-declare a member function, so we will have to inject a helper forwarder class. To make it easier to find the ultimate target, we remember it as the nested type name Outer<\/code>.<\/p>\n
template<typename OuterType>\r\nstruct MethodForwarder\r\n{\r\n    using Outer = OuterType;\r\n\r\n    auto outer() { return static_cast<Outer*>(this); }\r\n\r\n    HRESULT OnCallback() { return outer()->OnCallback(); }\r\n};\r\n\r\nstruct Widget final : IWidget,\r\n    CallbackWrapper<&MethodForwarder<Widget>::OnCallback>,\r\n{\r\n    ...\r\n    HRESULT OnCallback();\r\n    ...\r\n\r\n    HRESULT RegisterCallback()\r\n    {\r\n        SetCallback(this);\r\n    }\r\n};\r\n<\/pre>\n
There is a unique conversion from Widget<\/code> to ICallback<\/code> (namely through the CallbackWrapper<\/code>), but if you need multiple callbacks, you’re in for a lot more typing to resolve the ambiguous conversion:<\/p>\n
template<typename Outer>\r\nstruct MethodForwarder\r\n{\r\n    auto outer() { return static_cast<Outer*>(this); }\r\n\r\n    HRESULT OnCallback1() { return outer()->OnCallback1(); }\r\n    HRESULT OnCallback2() { return outer()->OnCallback2(); }\r\n};\r\n\r\nstruct Widget final : IWidget,\r\n    CallbackWrapper<&MethodForwarder<Widget>::OnCallback1>,\r\n    CallbackWrapper<&MethodForwarder<Widget>::OnCallback2>,\r\n{\r\n    ...\r\n    HRESULT OnCallback1();\r\n    HRESULT OnCallback2();\r\n    ...\r\n\r\n    HRESULT RegisterCallback()\r\n    {\r\n        SetCallback1(static_cast<CallbackWrapper<&MethodForwarder<Widget>::OnCallback1>*>\r\n                                                                                  (this));\r\n        SetCallback2(static_cast<CallbackWrapper<&MethodForwarder<Widget>::OnCallback2>*>\r\n                                                                                  (this));\r\n    }\r\n};\r\n<\/pre>\n
We can do some things to help a little with the verbosity: We can create a type alias, a variadic aggregator, and a helper function for casting to the correct base class:<\/p>\n
template<auto... Callbacks>\r\nstruct CallbackWrappers : CallbackWrapper<Callbacks>...\r\n{\r\n    template<auto Callback>\r\n    ICallback* GetCallback() {\r\n        return static_cast<CallbackWrapper<Callback>*>(this);\r\n    }\r\n};\r\n\r\nstruct Widget;\r\nusing WidgetForwarder = MethodForwarder<Widget>;\r\n\r\nstruct Widget final : IWidget,\r\n    CallbackWrappers<&WidgetForwarder::OnCallback1,\r\n                     &WidgetForwarder::OnCallback2>\r\n{\r\n    ...\r\n    HRESULT OnCallback1();\r\n    HRESULT OnCallback2();\r\n    ...\r\n\r\n    HRESULT RegisterCallback()\r\n    {\r\n        SetCallback1(GetCallback<&WidgetForwarder::OnCallback1>(this));\r\n        SetCallback2(GetCallback<&WidgetForwarder::OnCallback2>(this));\r\n    }\r\n};\r\n<\/pre>\n
An alternative to using the method forwarder would be to split the Widget into two parts, one that contains the bulk of the implementation and one that adds the callbacks.<\/p>\n
struct WidgetImpl : IWidget\r\n{\r\n    ...\r\n    HRESULT OnCallback1();\r\n    HRESULT OnCallback2();\r\n    ...\r\n};\r\n\r\nstruct Widget final : WidgetImpl,\r\n    CallbackWrappers<&WidgetImpl::OnCallback1,\r\n                     &WidgetImpl::OnCallback2>\r\n{\r\n};\r\n<\/pre>\n
This alternative version solves one problem but adds a new one: How does Widget\u00adImpl<\/code> access the callbacks? One idea is to use the CRTP pattern to allow WidgetImpl<\/code> to cast to its derived type:<\/p>\n
template<typename D>\r\nstruct WidgetImpl : IWidget\r\n{\r\n    ...\r\n    HRESULT OnCallback1();\r\n    HRESULT OnCallback2();\r\n    ...\r\n};\r\n\r\nstruct Widget final : WidgetImpl<Widget>,\r\n    CallbackWrappers<&WidgetImpl<Widget>::OnCallback1,\r\n                     &WidgetImpl<Widget>::OnCallback2>\r\n{\r\n};\r\n<\/pre>\n
But this is just about as clunky, so it doesn’t really save us much.<\/p>\n
We’re nowhere near done yet, because this still doesn’t work. We’ll pick up the investigation next time.<\/p>\n","protected":false},"excerpt":{"rendered":"
Trying to develop a slightly more efficient multi-headed snake.<\/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-105838","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
Trying to develop a slightly more efficient multi-headed snake.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/105838","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=105838"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/105838\/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=105838"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=105838"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=105838"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}