A customer was getting unresolved external errors from their C++\/WinRT code. How is that possible? C++\/WinRT is a header-only library; there is no static library that needs to be linked in. I mean, the way to resolve an unresolved external from a header is to link in the associated static or dynamic library, but for header-only libraries, there is no associated anything<\/i> to link in. So how can something be unresolved?<\/p>\n
C++\/WinRT is not just one header, but a series of headers. To reduce compile times, the C++\/WinRT headers for a particular component are split into multiple layers of headers. The lowest layer provides forward declarations for types, but almost no definitions. As you go higher up the layers, you get a little more: Maybe a class gets a definition, but the methods don’t get implemented until a still higher layer.<\/p>\n
When you include a C++\/WinRT header file, it includes declarations, definitions, and implementations for everything for which that header file is responsible, as well as its parent namespaces, but no more.<\/p>\n
Consider:<\/p>\n
namespace Contoso.Widgets\r\n{\r\n runtimeclass Widget\r\n {\r\n Widget();\r\n Contoso.Gadgets.Gadget GetGadget();\r\n void Reset();\r\n }\r\n}\r\n<\/pre>\nIf you include winrt\/Contoso.Widgets.h<\/code>, you get everything you need to create a Widget<\/code> and call its methods. However, you don’t<\/i> get everything you need to operate on Gadget<\/code> objects. You do have enough to call the GetGadget()<\/code> method, but you can’t do anything with the gadget until you include winrt\/Contoso.Gadgets.h<\/code>.<\/p>\n