{"id":104198,"date":"2020-09-09T07:00:00","date_gmt":"2020-09-09T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=104198"},"modified":"2020-09-09T06:07:22","modified_gmt":"2020-09-09T13:07:22","slug":"20200909-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20200909-00\/?p=104198","title":{"rendered":"The macros for declaring COM interfaces, revisited: C version"},"content":{"rendered":"

Quite some time ago, I covered The macros for declaring and implementing COM interfaces<\/a>. I spelled out the rules, but I didn’t go into much detail as to how the rules lead to the desired results.<\/p>\n

There have also been some changes to the rules in the intervening years, so this mini-series will be a refresh of the old rules.<\/p>\n

#undef  INTERFACE\r\n#define INTERFACE   ISample2\r\n\r\nDECLARE_INTERFACE_IID_(ISample2, ISample,\r\n                       \"5675B786-7BAC-4EA2-A020-F4E7A15E2073\")\r\n{\r\n    BEGIN_INTERFACE\r\n\r\n    \/*** IUnknown methods ***\/\r\n    STDMETHOD(QueryInterface)(THIS_ REFIID riid, void **ppv) PURE;\r\n    STDMETHOD_(ULONG,AddRef)(THIS) PURE;\r\n    STDMETHOD_(ULONG,Release)(THIS) PURE;\r\n\r\n    \/*** ISample methods ***\/\r\n    STDMETHOD(Method1)(THIS) PURE;\r\n    STDMETHOD_(int, Method2)(THIS) PURE;\r\n\r\n    \/*** ISample2 methods ***\/\r\n    STDMETHOD(Method3)(THIS_ int iParameter) PURE;\r\n    STDMETHOD_(int, Method4)(THIS_ int iParameter) PURE;\r\n\r\n    END_INTERFACE\r\n};\r\n<\/pre>\n
When this code is compiled by a C compiler, the macros expand as follows:<\/p>\n
\/* DECLARE_INTERFACE_IID_(ISample2, ISample, \"...\") *\/\r\ntypedef struct ISample2\r\n{\r\n    struct ISample2Vtbl* lpVtbl;\r\n} ISample2;\r\n\r\ntypedef struct ISample2Vtbl ISample2Vtbl;\r\n\r\nstruct ISample2Vtbl\r\n{\r\n    \/* BEGIN_INTERFACE *\/\r\n    void* b; \/* only on PowerPC *\/\r\n\r\n    \/*** IUnknown methods ***\/\r\n    \/* STDMETHOD(QueryInterface)(THIS_ REFIID riid, void **ppv) PURE; *\/\r\n    HRESULT (__stdcall* QueryInterface)(ISample2* This, REFIID riid, void** ppv);\r\n\r\n    \/* STDMETHOD_(ULONG,AddRef)(THIS) PURE; *\/\r\n    ULONG (__stdcall* AddRef)(ISample2* This);\r\n\r\n    \/* STDMETHOD_(ULONG,Release)(THIS) PURE; *\/\r\n    ULONG (__stdcall* Release)(ISample2* This);\r\n\r\n    \/*** ISample methods ***\/\r\n    \/* STDMETHOD(Method1)(THIS) PURE; *\/\r\n    HRESULT (__stdcall* Method1)(ISample2* This);\r\n\r\n    \/* STDMETHOD_(int, Method2)(THIS) PURE; *\/\r\n    int (__stdcall* Method2(ISample2* This);\r\n\r\n    \/*** ISample2 methods ***\/\r\n    \/* STDMETHOD(Method3)(THIS_ int iParameter) PURE; *\/\r\n    HRESULT (__stdcall* Method3)(int iParameter);\r\n\r\n    \/* STDMETHOD_(int, Method4)(THIS_ int iParameter) PURE; *\/\r\n    int (__stdcall* Method4)(int iParameter);\r\n\r\n    \/* END_INTERFACE *\/\r\n};\r\n<\/pre>\n
When compiled as C, the interface is formally defined as a structure consisting only of a vtable. The vtable is a sequence of function pointers, one for each virtual method.<\/p>\n
The parameters to the DECLARE_<\/code>INTERFACE_<\/code>IID_<\/code> macro are the interface being declared, its base interface, and the UUID for the interface. There’s also a version without the trailing underscore: DECLARE_<\/code>INTERFACE_<\/code>IID<\/code>. That version is for the case where there is no base interface. In practice, you will never use that version because every interface derives from IUnknown<\/code>. Basically, the only interface that would use the no-base-interface version is IUnknown<\/code> itself.<\/p>\n
There’s also a no-IID version of the macro: DECLARE_<\/code>INTERFACE_<\/code> (and DECLARE_<\/code>INTERFACE<\/code> for the one interface with no base interface). If you use this version, then you won’t be able to say __uuidof(ISample2)<\/code> in the C++ expansion to obtain the IID of the interface. We’ll see more about this when we dig into the C++ expansion.<\/p>\n
The BEGIN_<\/code>INTERFACE<\/code> macro does nothing on most systems, but on PowerPC, it generates a mysterious void*<\/code> at the start of the vtable. I don’t know why it’s there, but apparently that was part of the PowerPC ABI for vtables. A common mistake is forgetting the BEGIN_<\/code>INTERFACE<\/code> and END_<\/code>INTERFACE<\/code> macros. You don’t notice until somebody tries to use your header file on a PowerPC.<\/p>\n
Notice that all the methods of the base classes need to be redeclared in the derived class, so that the vtable is laid out properly. A common mistake is to omit the base interface methods, and you get away with it when compiling as C++ because the base interface methods are inherited. But C doesn’t have inheritance. You have to write it out.<\/p>\n
The STDMETHOD<\/code> and STDMETHOD_<\/code> macros generate a function pointer structure member, corresponding to a C++ virtual method, using the calling convention for COM methods, which happens to be __stdcall<\/code>. The STDMETHOD<\/code> macro is for methods returning HRESULT<\/code>, and the STDMETHOD_<\/code> macro is for methods that return something else.<\/p>\n
The PURE<\/code> macro expands to nothing. It’s used by the C++ expansion, which we’ll cover later.<\/p>\n
The THIS<\/code> and THIS_<\/code> macros expand to the This<\/code> parameter declaration, corresponding to the hidden this<\/code> parameter in C++. For methods with no parameters, use THIS<\/code> as the single parameter. For methods that have parameters, use THIS_<\/code> before the first parameter.<\/p>\n
The END_<\/code>INTERFACE<\/code> macro expands to nothing. There hasn’t yet been an architecture that required special treatment of the end of the vtable. But the macro is there in case some future architecture ends up needing something to go there.<\/p>\n
Next time, we’ll look at how these macros expand in C++.<\/p>\n","protected":false},"excerpt":{"rendered":"
Following the expansion.<\/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-104198","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
Following the expansion.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/104198","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=104198"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/104198\/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=104198"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=104198"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=104198"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}