Special connect() issue 2014

Volume 29 Number 12A

C++ : Visual C++ 2015 Brings Modern C++ to the Windows API

Kenny Kerr; issue 2014

Visual C++ 2015 is the culmination of a huge effort by the C++ team to bring modern C++ to the Windows platform. Over the last few releases, Visual C++ has steadily gained a rich selection of modern C++ language and library features that together make for an absolutely amazing environment in which to build universal Windows apps and components. Visual C++ 2015 builds on the remarkable progress introduced in those earlier releases and provides a mature compiler that supports much of C++11 and a subset of C++ 14. You might argue about the level of completeness, but I think it’s fair to say that the compiler supports the most important language features, enabling modern C++ to usher in a new era of library development for Windows. And that really is the key. As long as the compiler supports the development of efficient and elegant libraries, developers can get on with building great apps and components.

Rather than giving you a boring list of new features or pro­viding a high-level whirlwind tour of capabilities, I’ll instead walk you through the development of some traditionally complex code that is now, frankly, quite enjoyable to write, thanks to the maturity of the Visual C++ compiler. I’m going to show you something that’s intrinsic to Windows and at the heart of practically every significant current and future API.

It’s somewhat ironic that C++ is finally modern enough for COM. Yes, I’m talking about the Component Object Model that has been the foundation for much of the Windows API for years, and continues as the foundation for the Windows Runtime. While COM is undeniably tied to C++ in terms of its original design, borrowing much from C++ in terms of binary and semantic conventions, it has never been entirely elegant. Parts of C++ that were not deemed portable enough, such as dynamic_cast, had to be eschewed in favor of portable solutions that made C++ implementations more challenging to develop. Many solutions have been provided over the years to make COM more palatable for C++ developers. The C++/CX language extension is perhaps the most ambitious thus far by the Visual C++ team. Ironically, these efforts to improve Standard C++ support have left C++/CX in the dust and really make a language extension redundant.

To prove this point I’m going to show you how to implement IUnknown and IInspectable entirely in modern C++. There is nothing modern or appealing about these two beauties. IUnknown continues to be the central abstraction for prominent APIs like DirectX. And these interfaces—with IInspectable deriving from IUnknown—sit at the heart of the Windows Runtime. I’m going to show you how to implement them without any language extensions, interface tables or other macros—just efficient and elegant C++ with oodles of rich type information that lets the compiler and developer have a great conversation about what needs to be built.

The main challenge is to come up with a way to describe the list of interfaces that a COM or Windows Runtime class intends to implement, and to do so in a way that’s convenient for the developer and accessible to the compiler. Specifically, I need to make this list of types available such that the compiler can interrogate and even enumerate the interfaces. If I can pull that off I might be able to get the compiler to generate the code for the IUnknown QueryInterface method and, optionally, the IInspectable GetIids method, as well. It’s these two methods that pose the biggest challenge. Traditionally, the only solutions have involved language extensions, hideous macros or a lot of hard-to-maintain code.

Both method implementations require a list of interfaces that a class intends to implement. The natural choice for describing such a list of types is a variadic template:

template <typename ... Interfaces>
class __declspec(novtable) Implements : public Interfaces ...
{
};

The novtable __declspec extended attribute keeps any constructors and destructors from having to initialize the vfptr in such abstract classes, which often means a significant reduction in code size. The Implements class template includes a template parameter pack, thus making it a variadic template. A parameter pack is a template parameter that accepts any number of template arguments. The trick is that parameter packs are normally used to allow functions to accept any number of arguments, but in this case I’m describing a template whose arguments will be interrogated purely at compile time. The interfaces will never appear in a function parameter list.

One use of those arguments is already plain to see. The param­eter pack expands to form the list of public base classes. Of course, I’m still responsible for actually implementing those virtual functions, but at this point I can describe a concrete class that implements any number of interfaces:

class Hen : public Implements<IHen, IHen2>
{
};

Because the parameter pack is expanded to designate the list of base classes, it’s equivalent to what I might have written myself, as follows:

class Hen : public IHen, public IHen2
{
};

The beauty of structuring the Implements class template in this way is that I can now insert the implementation of various boilerplate code into the Implements class template while the developer of the Hen class can use this unobtrusive abstraction and largely ignore the magic behind it all.

So far, so good. Now I’ll consider the implementation of IUnknown itself. I should be able to implement it entirely inside the Implements class template, given the type of information the compiler now has at its disposal. IUnknown provides two facilities that are as essential to COM classes as oxygen and water are to humans. The first and perhaps simpler of the two is reference counting and is the means by which COM objects track their lifetime. COM prescribes a form of intrusive reference counting whereby each object is responsible for managing its own lifetime based on its awareness of how many outstanding references exist. This is in contrast to a reference counting smart pointer such as the C++11 shared_ptr class template, where the object has no knowledge of its shared ownership. You might argue about the pros and cons of the two approaches, but in practice the COM approach is often more efficient and it’s just the way COM works so you have to deal with it. If nothing else, you’ll likely agree that it’s a horrible idea to wrap a COM interface inside a shared_ptr!

I’ll begin with the only runtime overhead introduced by the Implements class template:

protected:
  unsigned long m_references = 1;
  Implements() noexcept = default;
  virtual ~Implements() noexcept
  {}

The defaulted constructor isn’t really overhead in itself; it simply ensures the resulting constructor—which will initialize the reference count—is protected rather than public. Both the reference count and the virtual destructor are protected. Making the reference count accessible to derived classes allows for more complex class composition. Most classes can simply ignore this, but do notice that I’m initializing the reference count to one. This is in contrast to popular wisdom that suggests the reference count should initially be zero because no references have been handed out yet. That approach was popularized by ATL and undoubtedly influenced by Don Box’s Essential COM, but it’s quite problematic, as a study of the ATL source code can well attest. Starting with the assumption that the ownership of the reference will immediately be assumed by a caller or attached to a smart pointer provides for a far less error-prone construction process.

A virtual destructor is a tremendous convenience in that it allows the Implements class template to implement the reference counting rather than forcing the concrete class itself to provide the implementation. Another option would be to use the curiously recurring template pattern to avoid the virtual function. Normally I’d prefer such an approach, but it would complicate the abstraction slightly, and because a COM class by its very nature has a vtable, there’s no compelling reason to avoid a virtual function here. With these primitives in place, it becomes a simple matter to implement both AddRef and Release inside the Implements class template. First, the AddRef method can simply use the InterlockedIncrement intrinsic to bump up the reference count:

virtual unsigned long __stdcall AddRef() noexcept override
{
  return InterlockedIncrement(&m_references);
}

That’s largely self-explanatory. Don’t be tempted to come up with some complex scheme whereby you might conditionally replace the InterlockedIncrement and InterlockedDecrement intrinsic functions with the C++ increment and decrement operators. ATL attempts to do so at a great expense of complexity. If efficiency is your concern, rather spend your efforts avoiding spurious calls to AddRef and Release. Again, modern C++ comes to the rescue with its support for move semantics and its ability to move the ownership of references without a reference bump. Now, the Release method is only marginally more complex:

virtual unsigned long __stdcall Release() noexcept override
{
  unsigned long const remaining = InterlockedDecrement(&m_references);
  if (0 == remaining)
  {
    delete this;
  }
  return remaining;
}

The reference count is decremented and the result is assigned to a local variable. This is important as this result should be returned, but if the object were to be destroyed it would then be illegal to refer to the member variable. Assuming there are no outstanding references, the object is simply deleted via a call to the aforementioned virtual destructor. This concludes reference counting, and the concrete Hen class is still as simple as before:

class Hen : public Implements<IHen, IHen2>
{
};

Now it’s time to consider the wonderful world of QueryInterface. Implementing this IUnknown method is a nontrivial exercise. I cover this extensively in my Pluralsight courses and you can read about the many weird and wonderful ways to roll your own implementation in “Essential COM” (Addison-Wesley Professional, 1998) by Don Box. Be warned that while this is an excellent text on COM, it’s based on C++98 and doesn’t represent modern C++ in any way. For the sake of space and time, I’ll assume you have some familiarity with the implementation of QueryInterface and focus instead on how to implement it with modern C++. Here’s the virtual method itself:

virtual HRESULT __stdcall QueryInterface(
  GUID const & id, void ** object) noexcept override
{
}

Given a GUID identifying a particular interface, QueryInterface should determine whether the object implements the desired interface. If it does, it must increment the reference count for the object and then return the desired interface pointer via the out parameter. If not, it must return a null pointer. Therefore, I’ll start with a rough outline:

*object = // Find interface somehow
if (nullptr == *object)
{
  return E_NOINTERFACE;
}
static_cast<::IUnknown *>(*object)->AddRef();
return S_OK;

So QueryInterface first attempts to find the desired interface somehow. If the interface isn’t supported, the requisite E_NO­INTERFACE error code is returned. Notice how I’ve already taken care of the requirement to clear the resulting interface pointer on failure. You should think of QueryInterface very much as a binary operation. It either succeeds in finding the desired interface or not. Don’t be tempted to get creative here and only conditionally respond favorably. Although there are some limited options allowed by the COM specification, most consumers will simply assume that the interface isn’t supported, regardless of what failure code you might return. Any mistakes in your implementation will undoubtedly cause you no end of debugging misery. QueryInterface is too fundamental to mess around with. Finally, AddRef is called through the resulting interface pointer again to support some rare but permissible class composition scenarios. Those aren’t explicitly supported by the Implements class template, but I’d rather set a good example here. It’s important to keep in mind that the reference-counting operations are interface-specific rather than object-specific. You can’t simply call AddRef or Release on any interface belonging to an object. You must honor the COM rules governing object identity, otherwise you risk introducing illegal code that will break in mysterious ways.

So how do I discover whether the requested GUID represents an interface that the class intends to implement? That’s where I can return to the type information the Implements class template collects via its template parameter pack. Remember, my goal is to allow the compiler to implement this for me. I want the resulting code to be as efficient as if I had written it by hand, or better. I’ll therefore do this query with a set of variadic function templates, function templates that themselves include template parameter packs. I’ll start with a BaseQueryInterface function template to kick things off:

virtual HRESULT __stdcall QueryInterface(
  GUID const & id, void ** object) noexcept override
{
  *object = BaseQueryInterface<Interfaces ...>(id);

BaseQueryInterface is essentially a modern C++ projection of the IUnknown QueryInterface. Instead of returning an HRESULT, it returns the interface pointer directly. Failure is obviously indicated with a null pointer. It accepts a single function argument, the GUID identifying the interface to find. More important, I expand the class template’s parameter pack in its entirety so that the BaseQueryInterface function can begin the process of enumerating the interfaces. You might at first think that because BaseQueryInterface is a member of the Implements class template it can simply access this list of interfaces directly, but I need to allow this function to peel off the first interface in the list, as follows:

template <typename First, typename ... Rest>
void * BaseQueryInterface(GUID const & id) noexcept
{
}

In this way, BaseQueryInterface can identify the first interface and leave the rest for a subsequent search. You see, COM has a number of specific rules to support object identity that QueryInterface must implement or at least honor. In particular, requests for IUnknown must always return the exact same pointer so a client can determine whether two interface pointers refer to the same object. Thus, the BaseQueryInterface function is a great place to implement some of these axioms. Therefore, I might begin by comparing the requested GUID with the first template argument that represents the first interface the class intends to implement. If that’s not a match, I’ll check whether IUnknown is being requested:

if (id == __uuidof(First) || id == __uuidof(::IUnknown))
{
  return static_cast<First *>(this);
}

Assuming one of these is a match, I simply return the unambiguous interface pointer for the first interface. The static_cast ensures the compiler won’t trouble itself with the ambiguity of multiple interfaces based on IUnknown. The cast merely adjusts the pointer to find the correct location in the class vtable, and because all interface vtables start with IUnknown’s three methods, this is perfectly valid.

While I’m here I might as well add optional support for IInspectable queries, as well. IInspectable is a rather odd beast. In some sense it’s the IUnknown of the Windows Runtime because every Windows Runtime interface projected into languages like C# and JavaScript must derive directly from IInspectable rather than merely IUnknown alone. This is an unfortunate reality to accommodate the way the Common Language Runtime implements objects and interfaces—which is in contrast to the way C++ works and how COM has traditionally been defined. It also has some rather unfortunate performance ramifications when it comes to object composition, but that’s a large topic I’ll cover in a follow-up article. As far as QueryInterface is concerned, I just need to ensure that IInspectable can be queried should this be the implementation of a Windows Runtime class rather than simply a classic COM class. Although the explicit COM rules about IUnknown don’t apply to IInspectable, I can simply treat the latter in much the same way here. But this presents two challenges. First, I need to discover whether any of the implemented interfaces derive from IInspectable. And, second, I need the type of one such interface so I can return a properly adjusted interface pointer without ambiguity. If I could assume that the first interface in the list would always be based on IInspectable, I might simply update BaseQueryInterface as follows:

if (id == __uuidof(First) ||
  id == __uuidof(::IUnknown) ||
  (std::is_base_of<::IInspectable, First>::value &&
  id == __uuidof(::IInspectable)))
{
  return static_cast<First *>(this);
}

Notice that I’m using the C++11 is_base_of type trait to determine whether the first template argument is an IInspectable-derived interface. This ensures that the subsequent comparison is excluded by the compiler should you be implementing a classic COM class with no support for the Windows Runtime. In this way I can seamlessly support both Windows Runtime and classic COM classes without any additional syntactic complexity for component developers and without any unnecessary runtime overhead. But this leaves the potential for a very subtle bug should you happen to list a non-IInspectable interface first. What I need to do is replace is_base_of with something that can scan the entire list of interfaces:

template <typename First, typename ... Rest>
constexpr bool IsInspectable() noexcept
{
  return std::is_base_of<::IInspectable, First>::value ||
    IsInspectable<Rest ...>();
}

IsInspectable still relies on the is_base_of type trait, but now applies it to each interface until a match is found. If no interfaces based on IInspectable are found, the terminating function is hit:

template <int = 0>
constexpr bool IsInspectable() noexcept
{
  return false;
}

I’ll get back to the curious nameless default argument in a moment. Assuming IsInspectable returns true, I need to find the first IInspectable-based interface:

template <int = 0>
void * FindInspectable() noexcept
{
  return nullptr;
}
template <typename First, typename ... Rest>
void * FindInspectable() noexcept
{
  // Find somehow
}

I can again rely on the is_base_of type trait, but this time return an actual interface pointer should a match be found:

#pragma warning(push)
#pragma warning(disable:4127) // conditional expression is constant
if (std::is_base_of<::IInspectable, First>::value)
{
  return static_cast<First *>(this);
}
#pragma warning(pop)
return FindInspectable<Rest ...>();

BaseQueryInterface can then simply use IsInspectable along with FindInspectable to support queries for IInspectable:

if (IsInspectable<Interfaces ...>() && 
  id == __uuidof(::IInspectable))
{
  return FindInspectable<Interfaces ...>();
}

Again, given the concrete Hen class:

class Hen : public Implements<IHen, IHen2>
{
};

The Implements class template will ensure the compiler generates the most efficient code whether IHen or IHen2 derives from IInspectable or simply from IUnknown (or some other interface). Now I can finally implement the recursive portion of QueryInterface to cover any additional interfaces, such as IHen2 in the previous example. BaseQueryInterface concludes by calling a FindInterface function template:

template <typename First, typename ... Rest>
void * BaseQueryInterface(GUID const & id) noexcept
{
  if (id == __uuidof(First) || id == __uuidof(::IUnknown))
  {
    return static_cast<First *>(this);
  }
  if (IsInspectable<Interfaces ...>() && 
    id == __uuidof(::IInspectable))
  {
    return FindInspectable<Interfaces ...>();
  }
  return FindInterface<Rest ...>(id);
}

Notice that I’m calling this FindInterface function template in much the same way as I originally called BaseQueryInterface. In this case, I’m passing it the rest of the interfaces. Specifically, I’m expanding the parameter pack such that it can again identify the first interface in the rest of the list. But this presents a problem. Because the template parameter pack isn’t expanded as function arguments, I can end up in a vexing situation where the language won’t let me express what I really want. But more on that in a moment. This “recursive” FindInterface variadic template is as you might expect:

template <typename First, typename ... Rest>
void * FindInterface(GUID const & id) noexcept
{
  if (id == __uuidof(First))
  {
    return static_cast<First *>(this);
  }
  return FindInterface<Rest ...>(id);
}

It separates its first template argument from the rest, returning the adjusted interface pointer if there’s a match. Otherwise, it calls itself until the interface list is exhausted. While I do loosely refer to this as compile-time recursion, it’s important to note that this function template—and the other similar examples in the Implements class template—are not technically recursive, not even at compile time. Each instantiation of the function template calls a different instantiation of the function template. For example, FindInterface<IHen, IHen2> calls FindInterface<IHen2>, which calls FindInterface<>. In order for it to be recursive, FindInterface<IHen, IHen2> would need to call FindInterface<IHen, IHen2>, which it does not.

Nevertheless, keep in mind that this “recursion” happens at compile time and it’s as if you’d written all those if statements by hand, one after the other. But now I hit a snag. How does this sequence terminate? When the template argument list is empty, of course. The problem is that C++ already defines what an empty template parameter list means:

template <>
void * FindInterface(GUID const &) noexcept
{
  return nullptr;
}

This is almost right, but the compiler will tell you that a function template isn’t available for this specialization. And, yet, if I don’t provide this terminating function, the compiler will fail to compile the final call when the parameter pack is empty. This is not a case for function overloading, because the list of arguments remains the same. Fortunately, the solution is simple enough. I can avoid the terminating function looking like a specialization by providing it with a nameless default argument:

template <int = 0>
void * FindInterface(GUID const &) noexcept
{
  return nullptr;
}

The compiler is happy, and if an unsupported interface is requested, this terminating function simply returns a null pointer and the virtual QueryInterface method will return the E_NOINTERFACE error code. And that takes care of IUnknown. If all you care about is classic COM, you can safely stop there as that’s all you’ll ever need. It’s worth reiterating at this point that the compiler will optimize this QueryInterface implementation, with its various “recursive” function calls and constant expressions, such that the code is at least as good as you could write by hand. And the same can be achieved for IInspectable.

For Windows Runtime classes, there’s the added complexity of implementing IInspectable. This interface isn’t nearly as fundamental as IUnknown, providing a dubious collection of facilities compared to the absolutely essential functions of IUnknown. Still, I’ll leave a discussion about that for a future article and focus here on an efficient and modern C++ implementation to support any Windows Runtime class. First, I’ll get the GetRuntimeClassName and GetTrustLevel virtual functions out of the way. Both methods are relatively trivial to implement and are also rarely used so their implementations can largely be glossed over. The GetRuntimeClassName method should return a Windows Runtime string with the full name of the runtime class that the object represents. I’ll leave that up to the class itself to implement should it decide to do so. The Implements class template can simply return E_NOTIMPL to indicate that this method isn’t implemented:

HRESULT __stdcall GetRuntimeClassName(HSTRING * name) noexcept
{
  *name = nullptr;
  return E_NOTIMPL;
}

Likewise, the GetTrustLevel method simply returns an enumerated constant:

HRESULT __stdcall GetTrustLevel(TrustLevel * trustLevel) noexcept
{
  *trustLevel = BaseTrust;
  return S_OK;
}

Notice that I don’t explicitly mark these IInspectable methods as virtual functions. Avoiding the virtual declaration allows the compiler to strip out these methods, should the COM class not actually implement any IInspectable interfaces. Now I’ll turn my attention to the IInspectable GetIids method. This is even more error-prone than QueryInterface. Although its implementation isn’t nearly as critical, an efficient compiler-generated implementation is desirable. GetIids returns a dynamically allocated array of GUIDs. Each GUID represents one interface that the object purports to implement. You might at first think this is simply a declaration of what the object supports via QueryInterface, but that’s correct only at face value. The GetIids method might decide to withhold some interfaces from publication. Anyway, I’ll begin with its basic definition:

HRESULT __stdcall GetIids(unsigned long * count, 
  GUID ** array) noexcept
{
  *count = 0;
  *array = nullptr;

The first parameter points to a caller-provided variable that the GetIids method must set to the number of interfaces in the resulting array. The second parameter points to an array of GUIDs and is how the implementation conveys the dynamically allocated array back to the caller. Here, I’ve started by clearing both parameters, just to be safe. I now need to determine how many interfaces the class implements. I would love to say just use the sizeof operator, which can provide the size of a parameter pack, as follows:

unsigned const size = sizeof ... (Interfaces);

This is mighty handy and the compiler is happy to report the number of template arguments that would be present if this parameter pack is expanded. This is also effectively a constant expression, producing a value known at compile time. The reason this won’t do, as I alluded to earlier, is because it’s extremely common for implementations of GetIids to withhold some interfaces that they don’t wish to share with everyone. Such interfaces are known as cloaked interfaces. Anyone can query for them via QueryInterface, but GetIids won’t tell you that they’re available. Thus, I need to provide a compile-time replacement for the variadic sizeof operator that excludes cloaked interfaces, and I need to provide some way to declare and identify such cloaked interfaces. I’ll start with the latter. I want to make it as easy as possible for component developers to implement classes so a relatively unobtrusive mechanism is in order. I can simply provide a Cloaked class template to “decorate” any cloaked interfaces:

template <typename Interface>
struct Cloaked : Interface {};

I can then decide to implement a special “IHenNative” interface on the concrete Hen class that’s not known to all consumers:

class Hen : public Implements<IHen, IHen2, Cloaked<IHenNative>>
{
};

Because the Cloaked class template derives from its template argument, the existing QueryInterface implementation continues to work seamlessly. I’ve just added a bit of extra type information I can now query for, again at compile time. For that I’ll define an IsCloaked type trait so I can easily query any interface to determine whether it has been cloaked:

template <typename Interface>
struct IsCloaked : std::false_type {};
template <typename Interface>
struct IsCloaked<Cloaked<Interface>> : std::true_type {};

I can now count the number of uncloaked interfaces again using a recursive variadic function template:

template <typename First, typename ... Rest>
constexpr unsigned CounInterfaces() noexcept
{
  return !IsCloaked<First>::value + CounInterfaces<Rest ...>();
}

And, of course, I’ll need a terminating function that can simply return zero:

template <int = 0>
constexpr unsigned CounInterfaces() noexcept
{
  return 0;
}

The ability to do such arithmetic calculations at compile time with modern C++ is stunningly powerful and amazingly simple. I can now continue to flesh out the GetIids implementation by requesting this count:

unsigned const localCount = CounInterfaces<Interfaces ...>();

The one wrinkle is that the compiler’s support for constant expressions is not yet very mature. While this is undoubtedly a constant expression, the compiler doesn’t yet honor constexpr member functions. Ideally, I could mark the CountInterfaces function templates as constexpr and the resulting expression would likewise be a constant expression, but the compiler doesn’t yet see it that way. On the other hand, I have no doubt that the compiler will have no trouble optimizing this code anyway. Now, if for whatever reason CounInterfaces finds no uncloaked interfaces, GetIids can simply return success because the resulting array will be empty:

if (0 == localCount)
{
  return S_OK;
}

Again, this is effectively a constant expression and the compiler will generate the code without a conditional one way or another. In other words, if there are no uncloaked interfaces, the remaining code is simply removed from the implementation. Otherwise, the implementation is compelled to allocate a suitably sized array of GUIDs using the traditional COM allocator:

GUID * localArray = static_cast<GUID *>(CoTaskMemAlloc(sizeof(GUID) * localCount));

Of course, this might fail, in which case I simply return the appropriate HRESULT:

if (nullptr == localArray)
{
  return E_OUTOFMEMORY;
}

At this point, GetIids has an array ready to be populated with GUIDs. As you might expect, I need to enumerate the interfaces one final time to copy each uncloaked interface’s GUID to this array. I’ll use a pair of function templates as I’ve done before:

template <int = 0>
void CopyInterfaces(GUID *) noexcept {}
template <typename First, typename ... Rest>
void CopyInterfaces(GUID * ids) noexcept
{
}

The variadic template (the second function) can simply use the IsCloaked type trait to determine whether to copy the GUID for the interface identified by its First template argument before incrementing the pointer. In that way, the array is traversed without having to keep track of how many elements it might contain or to where in the array it should be written. I also suppress the warning about this constant expression:

#pragma warning(push)
#pragma warning(disable:4127) // Conditional expression is constant
if (!IsCloaked<First>::value)
{
  *ids++ = __uuidof(First);
}
#pragma warning(pop)
CopyInterfaces<Rest ...>(ids);

As you can see, the “recursive” call to CopyInterfaces at the end uses the potentially incremented pointer value. And I’m almost done. The GetIids implementation can then conclude by calling CopyInterfaces to populate the array before returning it to the caller:

CopyInterfaces<Interfaces ...>(localArray);
  *count = localCount;
  *array = localArray;
  return S_OK;
}

All the while, the concrete Hen class is oblivious to all the work the compiler is doing on its behalf:

class Hen : public Implements<IHen, IHen2, Cloaked<IHenNative>>
{
};

And that’s as it should be with any good library. The Visual C++ 2015 compiler provides incredible support for Standard C++ on the Windows platform. It enables C++ developers to build beautifully elegant and efficient libraries. This supports both the development of Windows Runtime components in Standard C++, as well as their consumption from universal Windows apps written entirely in Standard C++. The Implements class template is just one example from Modern C++ for the Windows Runtime (see moderncpp.com).


Kenny Kerr is a computer programmer based in Canada, as well as an author for Pluralsight and a Microsoft MVP. He blogs at kennykerr.ca and you can follow him on Twitter at twitter.com/kennykerr.

Thanks to the following Microsoft technical expert for reviewing this article: James McNellis