Visual C++ 2015 将现代 C++ 引入 Windows API
Visual C++ 2015 是 C++ 团队付出巨大努力将现代 C++ 引入 Windows 平台的巅峰之作。在以前的几个版本中,Visual C++ 逐渐增加了相当丰富的现代 C++ 语言和库功能,这些一起组成了绝对令人惊叹的环境,可在其中构建通用的 Windows 应用和组件。Visual C++ 2015 的构建基于早期版本中所引入的显著进展,提供成熟的编译器来支持大部分 C++11 以及一个 C++ 2015 子集。您可能会对完整性水平方面有所议论,但我认为,恰当地说,此编译器支持最重要的语言功能,使现代 C++ 开创了 Windows 库开发的新时代。而且,这确实是关键。只要编译器支持简练高效的库开发,开发人员就可以继续构建强大的应用和组件。
我将完整地为您介绍一些传统复杂代码开发(由于 Visual C++ 编译器的成熟,现在确实很乐于编写这些代码),而不是只给您一个无聊的新功能列表或带您快速浏览这些功能。我将向您介绍 Windows 的本质以及几乎每个重要的当前和未来 API 的核心所在。
有点讽刺的是,对于 COM 而言,C++ 终于足够现代了。没错,我说的正是组件对象模型,它多年来一直就是大部分 Windows API 的基础,并且继续作为 Windows 运行时的基础。虽然不可否认 COM 与 C++ 在其原始设计方面相关联,并借鉴了 C++ 的二进制和语义约定方面的内容,但 COM 始终不是很完善。部分 C++ 被视为不够便携(如 dynamic_cast),需要避免采用便携解决方案,这会使 C++ 实现更不易于开发。多年来,提供了许多解决方案来为 C++ 开发人员提高 COM 的易用性。C++/CX 语言扩展也许是迄今为止由 Visual C++ 团队所提出的最具有前景的解决方案。讽刺的是,这些改进标准 C++ 支持的努力已经把 C++/CX 远远甩在后面,真正使语言扩展变得多余。
为了证明这一点,我将向您介绍如何完全在现代 C++ 中实现 IUnknown 和 IInspectable。关于这两个实现,既不现代也不吸引人。IUnknown 仍是重要 API(如 DirectX)的中心抽象。而且,随着 IInspectable 从 IUnknown 派生,这些接口位于 Windows 运行时的核心。我将向您介绍如何在无需任何语言扩展、接口表或其他宏的情况下实现它们。只需带有许多丰富类型信息的简练高效的 C++ 即可使编译器和开发人员就所需构建事项展开良好对话。
主要的挑战在于:以何种方式描述 COM 或 Windows 运行时类打算实现的接口列表,并且要以方便开发人员且编译器可以访问的方式执行此操作。尤其是,我需要提供此类型列表,以便编译器可以询问,甚至枚举这些接口。如果我可以实现上述操作,或许就能够让编译器生成 IUnknown QueryInterface 方法的代码,还可以选择生成 IInspectable GetIids 方法的代码。正是这两种方法构成了最大的挑战。一直以来,唯一的解决方案都涉及语言扩展、可怕的宏或者许多难以维护的代码。
这两种方法的实现都需要类打算实现的接口列表。描述这种类型列表的自然而然的选择就是可变参数模板:
template <typename ... Interfaces>
class __declspec(novtable) Implements : public Interfaces ...
{
};
novtable __declspec 扩展属性防止任何构造函数和析构函数在这种抽象类中初始化 vfptr,这通常意味着代码大小的显著降低。此 Implements 类模板包括一个模板参数包,从而使其成为可变参数模板。参数包是接受任意数量的模板实参的模板形参。其奥妙在于,参数包通常用于使函数接受任意数量的参数,但在这种情况下,我描述的是仅在编译时被询问参数的模板。这些接口绝不会在函数参数列表中显示。
使用这些参数的用户已经清楚地了解这一点。参数包扩展至形成公共基类列表。当然,我仍负责实际实现这些虚函数,但在这一点上,我可以描述实现任意数量接口的具体类:
class Hen : public Implements<IHen, IHen2>
{
};
由于参数包扩展至指定基类列表,这等同于我自己可能编写的内容,如下所示:
class Hen : public IHen, public IHen2
{
};
以这种方法构建 Implements 类模板的优点在于:现在我可以将各种样板代码的实现插入 Implements 类模板,而 Hen 类的开发人员可以使用此不显眼的抽象,并在很大程度上忽略这一抽象背后的魔力。
到目前为止一切顺利。现在,我会考虑 IUnknown 本身的实现。根据编译器现在可以处理的信息类型,我应该能够在 Implements 类模板中将其完全实现。IUnknown 提供两个对于 COM 类来说必不可少的功能,就像氧气和水之于人类。第一个功能是引用计数,或许它也是两个功能中较简单的功能,而且此功能是 COM 对象跟踪其生存期的方式。COM 规定侵入式引用计数的形式,以便每个对象根据其对存在的未完成引用数量的了解,来负责管理其自身的生存期。这与 C++11 shared_ptr 类模板等引用计数智能指针相反,在该类引用计数智能指针中对象并不知道其共享的所有权。您可能会争论这两种方法的利弊,但在实践中,COM 方法通常更为高效,这就是 COM 工作的方式,因此您必须解决这个问题。撇开其他不谈,您可能会认为在 shared_ptr 中封装 COM 接口是一个可怕的想法!
我将先探讨由 Implements 类模板引入的唯一运行时开销:
protected:
unsigned long m_references = 1;
Implements() noexcept = default;
virtual ~Implements() noexcept
{}
默认的构造函数并不是真的在自身中开销,它只确保生成的构造函数(将初始化引用计数)受到保护,而不是公开。引用计数和虚拟析构函数都会受到保护。使引用计数可用于派生类,以便进行更复杂的类复合。大多数类可以直接忽略这一点,但请注意,我正在将引用计数初始化为一。由于尚未分发任何引用,这有悖于建议引用计数最初应为零的常识。这种方法由 ATL 推广,且无疑受到 Don Box 的《Essential COM》(COM 本质论)的影响,但这一方法很有问题,对 ATL 源代码的研究可以很好地证明这一点。首先假设引用的所有权将立即由调用方假定或附加到智能指针,这会提供不容易出错的构造过程。
虚拟析构函数可以带来极大的便利,因为它允许 Implements 类模板实现引用计数,而不是强制具体类本身提供此实现。另一个选择是使用奇特的重复执行模板模式来避免虚拟函数。通常,我更喜欢这种方法,但它使抽象略微复杂化。由于 COM 类在其本质上具有 vtable,因此不必在此处避免虚拟函数。准备好这些原型之后,在 Implements 类模板中实现 AddRef 和 Release 就会变得非常简单。首先,AddRef 方法只需使用 InterlockedIncrement 内部函数来提升引用计数:
virtual unsigned long __stdcall AddRef() noexcept override
{
return InterlockedIncrement(&m_references);
}
大部分都很好理解。不要尝试提出一些复杂的方案,由此,您可能需要用 C++ 增量和递减运算符来有条件地替代 InterlockedIncrement 和 InterlockedDecrement 内部函数。ATL 尝试这样做是以复杂性为巨大代价的。如果您关注的是效率,那就不要费劲来避免对 AddRef 和 Release 的虚假调用了。同样,现代 C++ 通过支持移动语义和移动引用所有权这一功能来解决这一问题,而无需增加引用。现在,Release 方法只是稍微更为复杂:
virtual unsigned long __stdcall Release() noexcept override
{
unsigned long const remaining = InterlockedDecrement(&m_references);
if (0 == remaining)
{
delete this;
}
return remaining;
}
引用计数递减,并将结果分配到本地变量。这一点非常重要,因为该结果应该被返回,但如果要销毁该对象,则它将非法引用成员变量。假设没有未完成的引用,则仅通过调用前面所提及的虚拟析构函数即可删除该对象。这将得出引用计数,并且具体的 Hen 类仍然和之前一样简单:
class Hen : public Implements<IHen, IHen2>
{
};
现在是时候来探讨神奇的 QueryInterface 世界了。实现此 IUnknown 方法是一个重要的运用。在我的 Pluralsight 课程中,我进行了详细介绍,您也可以阅读 Don Box 的《Essential COM》(COM 本质论)(Addison-Wesley Professional, 1998) 一书,了解许多奇妙的方式,帮助您动手编写自己的实现。请注意,虽然这是一本有关 COM 的优秀书籍,但它基于 C++98,完全不能表现现代 C++。为了节省空间和时间,我假设您对 QueryInterface 实现有一定的了解,并转而关注如何使用现代 C++ 来实现它。下面是虚拟方法本身:
virtual HRESULT __stdcall QueryInterface(
GUID const & id, void ** object) noexcept override
{
}
鉴于 GUID 标识一个特定接口,QueryInterface 应确定该对象是否实现所需的接口。如果实现,则它必须增加该对象的引用计数,然后通过输出参数返回所需的接口指针。如果没有实现,则它必须返回 nulll 指针。因此,我先做个大体概述:
*object = // Find interface somehow
if (nullptr == *object)
{
return E_NOINTERFACE;
}
static_cast<::IUnknown *>(*object)->AddRef();
return S_OK;
首先 QueryInterface 尝试以某种方式查找所需的接口。如果不支持此接口,则返回必要的 E_NOINTERFACE 错误代码。请注意我如何考虑失败时所生成接口指针的清理要求。您应该把 QueryInterface 看作是二进制操作。它要么成功地找到所需接口,要么没有。不要尝试在这里发挥创造性,只有有条件地响应更具优势。虽然 COM 规范允许一些有限的选项,但大多数消费者会简单地认为不支持该接口,无论可能返回何种故障代码。实现中的任何错误无疑都会导致无穷无尽的痛苦调试。QueryInterface 是基础中的基础,不能出错。最后,再次通过生成的接口指针调用 AddRef,以支持一些罕见但允许的类复合情况。Implements 类模板不显式支持这些情况,但我宁愿在这里树立个好榜样。要牢记的一点就是,引用计数操作是特定于接口的,而并不是特定于对象的。您不能简单地在属于某个对象的任意接口上调用 AddRef 或 Release。您必须遵守管理对象标识的 COM 规则,否则您就有可能引入以神秘方式造成中断的非法代码。
那么,我要如何发现请求的 GUID 是否表示的是该类打算实现的接口?我从这里可以返回到 Implements 类模板通过其模板参数包收集的类型信息。请记住,我的目标是让编译器为我实现这一操作。我希望生成的代码就像我自己编写的代码一样高效,或者更为高效。因此,我将使用一组可变参数函数模板来执行此查询,这些函数模板本身就包含模板参数包。我将着手从 BaseQueryInterface 函数模板开始:
virtual HRESULT __stdcall QueryInterface(
GUID const & id, void ** object) noexcept override
{
*object = BaseQueryInterface<Interfaces ...>(id);
BaseQueryInterface 本质上是 IUnknown QueryInterface 的现代 C++ 投影。它直接返回接口指针,而不是返回 HRESULT。用 null 指针明显表示失败。它接受单个函数参数,GUID 标识要查找的接口。更重要的是,我整体扩展了类模板的参数包,以便 BaseQueryInterface 函数可以开始进行枚举接口的过程。起初,您可能认为这是因为 BaseQueryInterface 是 Implements 类模板的成员,它才能够直接访问此接口列表,但我需要允许此函数剔除列表中的第一个接口,如下所示:
template <typename First, typename ... Rest>
void * BaseQueryInterface(GUID const & id) noexcept
{
}
这样,BaseQueryInterface 可以识别第一个接口,然后保留剩余接口以便进行后续搜索。您会发现,COM 具有许多具体的规则来支持 QueryInterface 必须实现或至少遵守的对象标识。尤其是,对 IUnknown 的请求必须始终返回完全相同的指针,以便客户端确定两个接口指针是否引用了相同的对象。如此,BaseQueryInterface 函数成为实现某些公理的好去处。因此,我先来比较请求的 GUID 和代表该类打算实现的第一个接口的第一个模板参数。如果两者不匹配,我将检查是否正在请求 IUnknown:
if (id == __uuidof(First) || id == __uuidof(::IUnknown))
{
return static_cast<First *>(this);
}
假设其中有一个匹配,我只返回第一个接口的明确接口指针。static_cast 确保编译器不会在基于 IUnknown 的多个接口歧义方面产生问题。该转换只调整指针来查找类 vtable 中的正确位置,由于所有接口 vtable 都从 IUnknown 的三种方法开始,因此这完全有效。
虽然在这里,我也可以添加 IInspectable 查询的可选支持。IInspectable 是一个相当奇怪的“怪兽”。在某种意义上,IInspectable 是 Windows 运行时的 IUnknown,因为投射到 C# 和 JavaScript 等语言中的每个 Windows 运行时接口必须直接从 IInspectable 派生,而不是仅从 IUnknown 派生。这是一个令人遗憾的现实,以便适应通用语言运行时实现对象和接口的方式,这一方式与 C++ 的工作方式以及传统定义 COM 的方式相反。当涉及到对象组合时,这也会产生一些相当令人遗憾的性能影响,但这是一个范围广泛的主题,我将在后续文章中进行介绍。就 QueryInterface 而言,我只需确保这是 Windows 运行时类的实现,而不仅仅是经典的 COM 类的实现时,可以查询 IInspectable。虽然有关 IUnknown 的显式 COM 规则不适用于 IInspectable,但在这里我可以用几乎相同的方法对待后者。但这面临两大挑战。首先,我需要发现是否有任何实现的接口从 IInspectable 派生。其次,我需要这类接口的类型,以便返回适当调整过的接口指针,并且不会引起歧义。如果我可以假设列表中的第一个接口始终基于 IInspectable,则只需更新 BaseQueryInterface,如下所示:
if (id == __uuidof(First) ||
id == __uuidof(::IUnknown) ||
(std::is_base_of<::IInspectable, First>::value &&
id == __uuidof(::IInspectable)))
{
return static_cast<First *>(this);
}
请注意,我正在使用 C++11 is_base_of 类型特性来确定第一个模板参数是否为 IInspectable 派生的接口。这样可以确保当您在没有 Windows 运行时支持的情况下实现经典的 COM 类时,编译器将不执行后续比较。这样,我可以无缝地支持 Windows 运行时和经典的 COM 类,而对组件开发人员来说不会产生任何额外的句法复杂性,同时也没有任何不必要的运行时开销。但在您先列出非 IInspectable 接口的情况下,这会为一个非常难以发现的 bug 埋下隐患。我需要做的就是用能扫描整个接口列表的东西来替换 is_base_of:
template <typename First, typename ... Rest>
constexpr bool IsInspectable() noexcept
{
return std::is_base_of<::IInspectable, First>::value ||
IsInspectable<Rest ...>();
}
IsInspectable 仍依赖于 is_base_of 类型特性,现在将它应用于每个接口,直到找到一个匹配的接口。如果找不到基于 IInspectable 的接口,则会找到结束函数:
template <int = 0>
constexpr bool IsInspectable() noexcept
{
return false;
}
稍后我再介绍奇妙的无名默认参数。假设 IsInspectable 返回 true,我需要查找第一个基于 IInspectable 的接口:
template <int = 0>
void * FindInspectable() noexcept
{
return nullptr;
}
template <typename First, typename ... Rest>
void * FindInspectable() noexcept
{
// Find somehow
}
我可以再次依赖 is_base_of 类型特性,但在找到匹配的情况下,这次返回一个实际的接口指针:
#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 可以将 IsInspectable 和 FindInspectable 结合使用来支持 IInspectable 查询:
if (IsInspectable<Interfaces ...>() &&
id == __uuidof(::IInspectable))
{
return FindInspectable<Interfaces ...>();
}
同样,赋予具体的 Hen 类:
class Hen : public Implements<IHen, IHen2>
{
};
Implements 类模板将确保编译器生成最高效的代码,无论 IHen 或 IHen2 是从 IInspectable 还是从 IUnknown(或者某些其他接口)派生而来。现在,我终于可以实现 QueryInterface 的递归部分来涵盖任何其他接口,如上面示例中的 IHen2。BaseQueryInterface 最后调用 FindInterface 函数模板:
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);
}
请注意,我正在调用的 FindInterface 函数模板,其方式与我最初调用的 BaseQueryInterface 非常相似。在这种情况下,我将这些接口的其余部分传递给它。具体来说,我将扩展参数包,这样它就能再次识别列表其余部分中的第一个接口。但这面临一个问题。由于模板参数包无法扩展为函数参数,最终可能出现令人烦恼的情况,即语言无法表达出我真正想要表达的内容。稍后我会详细进行说明。“递归”FindInterface 可变参数模板正是您所期望的:
template <typename First, typename ... Rest>
void * FindInterface(GUID const & id) noexcept
{
if (id == __uuidof(First))
{
return static_cast<First *>(this);
}
return FindInterface<Rest ...>(id);
}
该模板将它的第一个模板参数与其余部分区分开来,如果存在匹配,则返回调整的接口指针。否则,该模板会调用其本身,直到接口列表耗尽。虽然我将这统统称为编译时递归,但值得注意的是,即使在编译时,此函数模板以及 Implements 类模板中其他类似的示例都不是技术上的递归。每个函数模板的实例化都调用不同的函数模板实例化。例如,FindInterface<IHen, IHen2> 调用 FindInterface<IHen2>,这会调用 FindInterface<>。为了使其具有递归性,FindInterface<IHen, IHen2> 可能需要调用 FindInterface<IHen, IHen2>,但实际上它并不会这样做。
尽管如此,请记住,此“递归”在编译时发生,这就像是您手动编写所有这些 if 语句,一个接一个。但现在我遇到了阻碍。这一序列如何终止?当然,是在模板参数列表为空的时候。问题是 C++ 已经定义了空的模板参数列表意味着什么:
template <>
void * FindInterface(GUID const &) noexcept
{
return nullptr;
}
这几乎是正确的,但编译器会告诉您函数模板不适用于此特殊化。但是,如果我不提供此结束函数,在参数包为空时,编译器将无法编译最后一次调用。这不是函数重载的情况,因为参数列表是相同的。幸运的是,解决方案非常简单。我可以为结束函数提供一个无名默认参数,来避免其看上去像特殊化:
template <int = 0>
void * FindInterface(GUID const &) noexcept
{
return nullptr;
}
该编译器令人满意,如果请求不受支持的接口,此结束函数只需返回一个 null 指针,虚拟 QueryInterface 方法将返回 E_NOINTERFACE 错误代码。并且这处理了 IUnknown。如果您所关心的只是经典 COM,到这儿您就可以放心地停下来了,因为这些就是您所需要的一切。值得重申的一点就是,编译器将通过其各种“递归”函数调用和常量表达式来优化 QueryInterface 实现,这样一来,该代码就跟您手动编写的一样好。IInspectable 可以达到同样的效果。
对于 Windows 运行时类,实现 IInspectable 会增加复杂性。该接口完全不如 IUnknown 般基础,相比 IUnknown 所提供的绝对必要的函数,该接口提供可疑的工具集合。不过,我会在以后的文章中讨论此问题,本文关注的是支持任何 Windows 运行时类的高效且现代的 C++ 实现。首先,我将挑出 GetRuntimeClassName 和 GetTrustLevel 虚拟函数。这两种方法都比较容易实现,并且也很少使用,因此它们的实现可以基本省略。GetRuntimeClassName 方法应返回带有该对象所表示的运行时类完整名称的 Windows 运行时字符串。在该类决定这样做的情况下,我将决定权留给类自身来实现。Implements 类模板可以返回 E_NOTIMPL 来指明尚未实现此方法:
HRESULT __stdcall GetRuntimeClassName(HSTRING * name) noexcept
{
*name = nullptr;
return E_NOTIMPL;
}
同样,GetTrustLevel 方法返回枚举的常量:
HRESULT __stdcall GetTrustLevel(TrustLevel * trustLevel) noexcept
{
*trustLevel = BaseTrust;
return S_OK;
}
请注意,我并没有将这些 IInspectable 方法显式标记为虚拟函数。在 COM 类实际上并未实现任何 IInspectable 接口的情况下,避免虚拟声明允许编译器去掉这些方法。现在,我将注意力转移到 IInspectable GetIids 方法。这甚至比 QueryInterface 更容易出错。尽管 IInspectable GetIids 方法的实现几乎不怎么关键,但需要编译器生成的高效实现。GetIids 返回 GUID 动态分配的数组。每个 GUID 代表一个对象想要实现的接口。起初,您可能认为这只是该对象通过 QueryInterface 所支持内容的声明,但只有从表面上看,这一理解才正确。GetIids 方法可能会决定从发布中保留一些接口。不管怎样,我将从其基本的定义着手:
HRESULT __stdcall GetIids(unsigned long * count,
GUID ** array) noexcept
{
*count = 0;
*array = nullptr;
第一个参数指向调用方提供的变量,GetIids 方法必须将此变量设置为生成数组中接口的数量。第二个参数指向一个 GUID 的数组,该参数是实现将动态分配数组传送回调用方的方式。在这里,为了安全起见,我首先清除了这两个参数。我现在需要确定该类要实现的接口数量。我想说,只需使用能提供参数包大小的 sizeof 运算符,如下所示:
unsigned const size = sizeof ... (Interfaces);
这非常便捷,该编译器令人满意地报告扩展此参数包时会显示模板参数的数量。这也是有效的常量表达式,生成编译时已知的值。如前所述,不执行此操作的原因是因为以下情况相当常见,即 GetIids 实现会保留一些不想与每个人共享的接口。这些接口称为掩蔽的接口。任何人都可以通过 QueryInterface 查询这些接口,但是 GetIids 不会告诉您这些接口可用。因此,我需要为排除掩蔽接口的可变参数 sizeof 运算符提供编译时替代,并且需要提供某种方式来声明和标识这类掩蔽的接口。我将从后者着手。我希望使其尽可能简化组件开发人员实现类的工作,因此一种相对不显眼的机制在这里很适用。我只需提供 Cloaked 类模板来“修饰”任何掩蔽的接口:
template <typename Interface>
struct Cloaked : Interface {};
然后,我可以决定在所有消费者都不知道的具体 Hen 类上实现特殊的“IHenNative”接口:
class Hen : public Implements<IHen, IHen2, Cloaked<IHenNative>>
{
};
因为 Cloaked 类模板从其模板参数中派生而来,因此现有的 QueryInterface 实现可以继续无缝地工作。我只添加了一点额外的类型信息,现在就可以再次在编译时对其进行查询。为此,我将定义 IsCloaked 类型特性,这样我可以轻松地查询任何接口以确定其是否被掩蔽:
template <typename Interface>
struct IsCloaked : std::false_type {};
template <typename Interface>
struct IsCloaked<Cloaked<Interface>> : std::true_type {};
现在,我可以使用递归可变参数函数模板,再次对未掩蔽接口的数量进行计数:
template <typename First, typename ... Rest>
constexpr unsigned CounInterfaces() noexcept
{
return !IsCloaked<First>::value + CounInterfaces<Rest ...>();
}
当然,我还需要只返回零的结束函数:
template <int = 0>
constexpr unsigned CounInterfaces() noexcept
{
return 0;
}
能在编译时使用现代的 C++ 执行这种算数计算的这一功能极为强大,又惊人地简单。现在,我可以通过请求该计数来继续填充 GetIids 实现:
unsigned const localCount = CounInterfaces<Interfaces ...>();
存在的一个小问题就是,编译器对常量表达式的支持还不是很成熟。虽然这无疑是一个常量表达式,但编译器不遵守 constexpr 成员函数。理想情况下,我可以将 CountInterfaces 函数模板标记为 constexpr,所生成的表达式将同样是一个常量表达式,但编译器却不这么认为。另一方面,毋庸置疑,编译器在优化此代码时不会有太大困难。现在,如果 CounInterfaces 因任何原因没有找到非掩蔽的接口,GetIids 只需返回成功信息,因为所生成的数组将为空:
if (0 == localCount)
{
return S_OK;
}
同样,这实际上是一个常量表达式,编译器将生成代码,而无需某种形式的条件。换言之,如果非掩蔽的接口不存在,则直接从实现中删除剩余代码。否则,该实现不得不使用传统的 COM 分配器来分配适当大小的 GUID 数组:
GUID * localArray = static_cast<GUID *>(CoTaskMemAlloc(sizeof(GUID) * localCount));
当然,这可能失败,在这种情况下,我只返回相应的 HRESULT:
if (nullptr == localArray)
{
return E_OUTOFMEMORY;
}
此时,GetIids 拥有一个准备填充 GUID 的数组。正如您所料,我需要最后一次枚举这些接口,来将每个非掩蔽接口的 GUID 复制到此数组。我将像以前所做过的操作一样,使用一对函数模板:
template <int = 0>
void CopyInterfaces(GUID *) noexcept {}
template <typename First, typename ... Rest>
void CopyInterfaces(GUID * ids) noexcept
{
}
可变参数模板(第二个函数)只需使用 IsCloaked 类型特性即可确定在递增指针之前,是否要复制由其第一个模板参数所标识的接口 GUID。通过这种方式,在遍历该数组时,无需追踪它所包含的元素数量,以及它应在数组中进行编写的位置。我还禁止显示有关此常量表达式的警告:
#pragma warning(push)
#pragma warning(disable:4127) // Conditional expression is constant
if (!IsCloaked<First>::value)
{
*ids++ = __uuidof(First);
}
#pragma warning(pop)
CopyInterfaces<Rest ...>(ids);
正如您所见,最终对 CopyInterfaces 的“递归”调用使用了潜在递增的指针值。快要大功告成了。然后 GetIids 实现在将 CopyInterfaces 返回到调用方之前,最后可以调用它来填充该数组:
CopyInterfaces<Interfaces ...>(localArray);
*count = localCount;
*array = localArray;
return S_OK;
}
同时,具体的 Hen 类无视编译器以它的名义所做的所有工作:
class Hen : public Implements<IHen, IHen2, Cloaked<IHenNative>>
{
};
这是因为它应该适用于任何好的库。Visual C++ 2015 编译器为 Windows 平台上的标准 C++ 提供出色支持。它使 C++ 开发人员构建非常简练有效的库。它同时支持标准 C++ 中的 Windows 运行时组件的开发,以及来自于完全在标准 C++ 中编写的通用 Windows 应用的消耗。Implements 类模板只是适用于 Windows 运行时的现代 C++ 的一个示例(请参阅 moderncpp.com)。
Kenny Kerr 是加拿大的一名计算机程序员,也是 Pluralsight 的作者以及 Microsoft MVP。他的博客网址是 kennykerr.ca,您可以通过 Twitter twitter.com/kennykerr 关注他。
衷心感谢以下 Microsoft 技术专家对本文的审阅:James McNellis