Visual C++ 2015引入更新的C++ 特性到Windows API
Visual C++ 2015 是 C++ 團隊付出巨大努力將現(xiàn)代C++引入windows平臺的成果。在***的幾個發(fā)行版本里，VC++已經(jīng)逐步添加了現(xiàn)代C++語言以及庫的特色，這些結(jié)合在一起會創(chuàng)造一個用于構(gòu)建通用windows App和組件的絕對驚艷的開發(fā)環(huán)境。Visual C++2015建立在早期版本引入的驚人進步，提供了成熟的、支持大多數(shù)C++11特性以及C++ 2015子集的編譯器。你或許會懷疑編譯器支持的完整程度，公正地說，我認為他能支持大部分重要的語言特性，支持現(xiàn)代C++將會迎來windows 程序庫開發(fā)一片新的天地。這才是關(guān)鍵。只要編譯器支持一個高效優(yōu)雅的庫的開發(fā)環(huán)境，開發(fā)者就能構(gòu)建偉大的app和組件。
這里我不會讓你看一個枯燥的新特性列表，或者走馬觀花地看下它的功能，而是會帶你瀏覽下一些傳統(tǒng)情況下的復(fù)雜代碼現(xiàn)在如何讓人相當愉快書寫。當然，這得益于成熟的Visual C++編譯器。我將會向你展示windows的一些本質(zhì)，在現(xiàn)在或?qū)鞟PI中實際上都是很重要的本質(zhì)。
頗具諷刺意味的是,對于COM來說,C++已經(jīng)足夠現(xiàn)代了.是的,我在談?wù)摻M件對象模型(COM),多年以來,它一直是大多數(shù)Windows API的基石.同時,它也繼續(xù)作為Windows運行時的基石.COM無可爭辯的依附于C++的原始設(shè)計,借鑒了許多來自C++的二進制和語義約定,但是它從來都不夠優(yōu)雅.C++的部分內(nèi)容被認為可移植性不夠,如dynamic_cast,必須避免使用它,以采用可移植的解決方案,這使得C++的開發(fā)實現(xiàn)更具挑戰(zhàn)性.近些年已經(jīng)為C++開發(fā)者提供了許多解決方案,讓COM變得更加可移植.C++/CX 語言拓展,可能是Visual C++團隊到目前為止***野心的.具有諷刺意味的是,這些提升標準C++支持的努力,已經(jīng)將C++/CX棄之不顧了,也讓語言拓展變得冗余.
為了證明這點,我會展示給你如何完整的用現(xiàn)代C++實現(xiàn)IUnknown和IInspectable接口.關(guān)于這兩個接口沒有什么現(xiàn)代的或吸引力的東西.IUnknown繼續(xù)成為卓越API,如DirectX,的集中抽象.這些接口--IInspectable繼承自IUnknown--位于Windows運行時的中心.我將展示給你如何不用任何語言拓展來實現(xiàn)它們,接口表或其它宏--只需要包含大量類型信息的高效和優(yōu)雅的C++,就可以讓編譯器和開發(fā)者擁有,關(guān)于如何創(chuàng)建所需的,優(yōu)異的人機對話.
主要的問題是, 如何列出 COM 或 Windows Runtime 類需要實現(xiàn)的接口, 而且要方便開發(fā)者使用, 和編譯器訪問. 比如, 列出所有可用類型, 以便編譯器查詢, 甚至枚舉出相應(yīng)的接口. 要是能實現(xiàn)這樣的功能, 也許就能讓編譯器生成 IUnknown QueryInterface 甚至 IInspectable GetIids 方法的代碼. 這兩個方法才是問題的關(guān)鍵. 按照傳統(tǒng)的觀念, 唯一的解決辦法涉及到語言擴展(language extensions), 萬惡的宏定義, 以及一堆難以維護的代碼.
兩種方法的實現(xiàn), 都用到類需要實現(xiàn)的接口. 可變參數(shù)模板( variadic template)是***:
- template <typename ... Interfaces>
- class __declspec(novtable) Implements : public Interfaces ...
- {
- };
__declspec(novtable)拓展屬性可以防止構(gòu)造函數(shù)和析構(gòu)函數(shù)初始化抽象類的vfptr,這通常意味著減少大量的代碼.實現(xiàn)類模板包括一個模板參數(shù)包,這使它成為一個可變模板.一個參數(shù)包即一個模板參數(shù)接受任意數(shù)目的模板參數(shù)變量.但是在這種情況下,我描述的模板參數(shù)將只會在編譯時進行查詢.接口將不會出現(xiàn)在函數(shù)的參數(shù)列表之中.
這些參數(shù)的一個使用已經(jīng)顯而易見.參數(shù)包拓展后成為公共基礎(chǔ)類的參數(shù)列表.當然,我仍然有責(zé)任到***實現(xiàn)這些虛函數(shù),但是此刻我會描述一個實現(xiàn)任意數(shù)目接口的一個具體類:
- class Hen : public Implements<IHen, IHen2>
- {
- };
因為參數(shù)包拓展為指定基礎(chǔ)類的列表,所有它等同于下面我可能會寫出的代碼:
- class Hen : public IHen, public IHen2
- {
- };
用這種方式結(jié)構(gòu)化實現(xiàn)類模板的美妙之處在于,我現(xiàn)在可以,在實現(xiàn)類模板中,寫入各種樣版實現(xiàn)代碼,而Hen類的開發(fā)者則可以使用這種不唐突的抽象,同時大量忽略隱含的細節(jié).
到目前為止,一切都很好.現(xiàn)在,我將考慮IUnknown的實現(xiàn).我應(yīng)該可以在實現(xiàn)類模板中完整的實現(xiàn)它,并提供編譯器現(xiàn)在所擁有的類型信息.IUnknown提供了對于COM類非常重要的兩種工具,就像氧氣和水對于人類一樣.***個可能簡單些的是引用計數(shù),這也是COM對象跟蹤它們生命周期的方式.COM規(guī)定一種侵入式的引用計數(shù),它借助于每個對象,統(tǒng)計多少個外部引用存在,來負責(zé)管理自己的生命周期.這與智能指針,如C++ 11的shared_ptr類,的引用計數(shù)恰恰相反,智能指針對象并不知道它的共享關(guān)系.你可能會爭論這兩種方式的優(yōu)缺點.但是,實際上COM的方法通常更高效,這也是COM的工作方式,你必須處理它.如果沒有其它的,你很可能會同意這點,在shared_ptr里面包裝一個COM接口會是一件極不友好的事情!
我將以只有運行時的開銷作為開始,它是通過實現(xiàn)類模板介紹的:
- protected:
- unsigned long m_references = 1;
- Implements() noexcept = default;
- virtual ~Implements() noexcept
- {}
默認構(gòu)造函數(shù)并不是真正的開銷所在,它只是簡單的確保最終的構(gòu)造函數(shù)--它將初始化引用計數(shù)--為protected而不是public的.引用計數(shù)和虛構(gòu)造函數(shù)都是protected的.讓派生類訪問引用計數(shù),是為了允許更復(fù)雜的類組合.大多數(shù)類可以簡單的忽略它,但是需要注意的是,我正初始化引用計數(shù)為1.這和通常建議初始化引用計數(shù)為0,形成鮮明的對比,因為此時并沒有處理引用.這個方式在ATL中非常流行,明顯受到Don Box的COM本質(zhì)論的影響,但是這是非常有問題的,ATL的源代碼的研究可以作為佐證.開始于這個假設(shè),即引用的所有權(quán)將會立即由調(diào)用者獲得,或者依附于一個提供更少錯誤構(gòu)造處理的智能指針.
虛析構(gòu)函數(shù)提供了很大的便利性,它允許實現(xiàn)類模板實現(xiàn)引用計數(shù),而不是強制實現(xiàn)類本身來提供實現(xiàn).另一個選項,是使用奇特的遞歸模板模式(Curiously Recurring Template Pattern)來避免使用虛函數(shù).通常我會選擇這個方法,但是它會稍微增加抽象的復(fù)雜性,同時,因為COM類本身有一個vtable,所以這里也沒有什么理由去避免使用虛函數(shù).有了這些基本類型之后,在實現(xiàn)類模板中實現(xiàn)AddRef和Release將會變得非常簡單.首先,AddRef方法可以簡單的使用InterlockedIncrement來增加引用計數(shù):
- virtual unsigned long __stdcall AddRef() noexcept override
- {
- return InterlockedIncrement(&m_references);
- }
這不言自明.不要想出某些復(fù)雜的方法,通過使用C++的加減操作符來有條件的替換InterlockedIncrement和InterlockedDecrement函數(shù).ATL通過極大的增加復(fù)雜性去做這個嘗試.如果你考慮效率,寧可為避免調(diào)用AddRef和Release產(chǎn)生謬誤而多花心思.同樣的,現(xiàn)代C++增加了對move語義的支持,以及增加轉(zhuǎn)移引用所有權(quán)的能力.現(xiàn)在,Release方法只是略顯復(fù)雜:
- virtual unsigned long __stdcall Release() noexcept override
- {
- unsigned long const remaining = InterlockedDecrement(&m_references);
- if (0 == remaining)
- {
- delete this;
- }
- return remaining;
- }
引用計數(shù)減少后,結(jié)果被賦值給臨時變量.這很重要,因為結(jié)果需要返回.但是如果對象銷毀了,引用此對象的成員變量就是非法的了.假定沒有其它未處理的引用,這個對象就通過前面說到的虛析構(gòu)函數(shù)刪除了.這就是引用計數(shù)的結(jié)論,實現(xiàn)類Hen仍然和之前的一樣簡單:
- class Hen : public Implements<IHen, IHen2>
- {
- };
現(xiàn)在，到了想象一下QueryInterface的奇妙世界的時間了。實現(xiàn)IUnknown方法是一個很重要的實踐。在我的Pluralsight課程中，我廣泛的實現(xiàn)了它。你可以在Don Box編寫的<<COM本質(zhì)論>>(Addison-Wesley Professional，1998)一書中，閱讀關(guān)于實現(xiàn)你自己的IUnknown的奇妙的和不可思議的方法。需要注意的是，雖然這是一本關(guān)于COM的優(yōu)秀書籍，但是它是基于C++98的，并沒有呈現(xiàn)出任何現(xiàn)代C++的特征。為了節(jié)省時間，我假定你已經(jīng)熟悉了QueryInterface的實現(xiàn)過程，并集中于如何用現(xiàn)代C++實現(xiàn)它。下面是虛函數(shù)本身:
- virtual HRESULT __stdcall QueryInterface(
- GUID const & id, void ** object) noexcept override
- {
- }
給定一個GUID用來標識一個特別的接口之后，QueryInterface應(yīng)該來決定一個對象是否實現(xiàn)了需要的接口。如果實現(xiàn)了，它必須減少這個對象的引用計數(shù)，同時通過外部參數(shù)來返回所需的接口指針。如果沒有實現(xiàn)，它必須返回一個空指針。因此，我將以一個粗略的輪廓來作為開始:
- *object = // Find interface somehow
- if (nullptr == *object)
- {
- return E_NOINTERFACE;
- }
- static_cast<::IUnknown *>(*object)->AddRef();
- return S_OK;
QueryInterface首先會嘗試設(shè)法查找所需的接口。如果接口受不支持，則返回E_NOINTERFACE錯誤碼。請注意，我是如何按照要求處理接口指針不支持的情況。你應(yīng)該把QueryInterface接口看作是二元的操作。它要么成功找到所需的接口，要么查找失敗。不要嘗試發(fā)揮創(chuàng)造性，只需要依據(jù)條件響應(yīng)即可。盡管COM規(guī)范有一些限制項，但是大多數(shù)消費者都會簡單的假定接口不受支持，而不管你會返回何種錯誤碼。在你的實現(xiàn)中的任何錯誤，都毫無疑問的會導(dǎo)致你陷入調(diào)試的深淵。QueryInterface是非?；A(chǔ)的，不能胡亂對待。***，AddRef由接口指針再次調(diào)用，用來支持某種極少的而又允許的類組合場景。這些不受實現(xiàn)類模板的顯式支持，但是我情愿在這里做一個表率。重要的是，記住引用計數(shù)操作是面向接口的，而不是面向?qū)ο蟮?。你不?簡單的，在屬于一個對象的任意接口上面，調(diào)用AddRef或者Release。你必須依賴COM規(guī)則來管理對象，否則你會冒險引入以不可思議的方式崩潰的非法代碼。
但是我如何得知，請求的GUID是否就代表著類想要實現(xiàn)的接口呢？我需要回到實現(xiàn)類模板收集的類型信息的地方，其中類型信息通過它的模板參數(shù)包來收集。請記住，我的目標是準許編譯器為我實現(xiàn)它。我希望最終代碼，和我手寫的一樣高效，甚至更好。我會通過可變函數(shù)模板集合來進行查詢，函數(shù)模板自身包括模板參數(shù)包。我將以BaseQueryInterface函數(shù)模板作為開始:
- virtual HRESULT __stdcall QueryInterface(
- GUID const & id, void ** object) noexcept override
- {
- *object = BaseQueryInterface<Interfaces ...>(id);
BaseQueryInterface本質(zhì)上是IUnknown QueryInterface的現(xiàn)代C++版本。它直接返回接口指針而不是HRESULT類型。空指針則表明失敗的情況。它接受單一函數(shù)參數(shù)，GUID標識著要查找的接口。更重要的是，我拓展了類模板參數(shù)包為完整模式，這樣，BaseQueryInterface函數(shù)就可以開始枚舉接口的處理過程。 起初你可能會認為，由于BaseQueryInterface是實現(xiàn)類模板的成員函數(shù)，所以它可以簡單直接的訪問接口的鏈表，但是我需要準許這個函數(shù)剝離鏈表中的***個接口，就像下面這樣:
- template <typename First, typename ... Rest>
- void * BaseQueryInterface(GUID const & id) noexcept
- {
- }
按照這種方式，BaseQueryInterface函數(shù)能識別***個接口，并且給接下來的搜索留有余地?？窗?，COM有一定數(shù)量的特殊規(guī)則來支持QueryInterface 實現(xiàn)或至少接受對象識別。尤其是請求IUnknown，必須總是返回確切相同的指針，客戶端才能確定兩個接口的指針是否來自同一個對象。因此，BaseQueryInterface函數(shù)最棒的地方就是實現(xiàn)了這些假設(shè)。所以，可以從***代表類想要實現(xiàn)的***個接口的模板參數(shù)的GUID請求的對比開始。如果不匹配，我會檢查IUnknown是否開始請求了：
- if (id == __uuidof(First) || id == __uuidof(::IUnknown))
- {
- return static_cast<First *>(this);
- }
假設(shè)有一個匹配的，我直接準確無誤的返回了***個接口的指針。static_cast 能確保編譯器基于IUnknown的多種接口不會引起歧義。cast只是校準了指針，讓類的vtable能找到正確的指針位置，因為所有vtable接口是以IUnknown的三個方法開始的，這非常符合邏輯。
而我不妨同樣添加IInspectable查詢的可選支持。IInspectable相當變態(tài)，在某種意義上，它是Windows運行時接口，因為每個Windows運行時預(yù)計編程語言（如 C# 和 JavaScript）必須直接來自IInspectable，而不僅僅只是IUnknown接口。相對于C++的工作方式和COM傳統(tǒng)的定義方式，以適應(yīng)公共語言運行庫的方式實現(xiàn)對象和接口是不幸的事實。更不幸的是當對象組合的時候?qū)π阅艿挠绊?，我會在下文中討論?/span>至于QueryInterface，我只需確保IInspectable能被查詢，它應(yīng)該是一個Windows運行時類的實現(xiàn)，而不是一個簡單的典型COM類。雖然關(guān)于IUnknown的明確的COM規(guī)則不適用于IInspectable，我可以簡單的用相同的方式對待后者。但這兩個挑戰(zhàn)。首先，需要了解是否有任何IInspectable派生出來的接口實現(xiàn)。第二，需要了解接口的類型，這樣就可以正確的返回一個沒有歧義的調(diào)整過的接口指針。假定列表中的***個接口都是基于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 的特性，來確定***個模板參數(shù)是一個IInspectable的衍生接口。萬一實現(xiàn)典型的COM類不支持Windows運行時，就能確保隨后的對照是由編譯器排除的。這樣我可以無縫地支持Windows運行時和經(jīng)典的COM類，即沒有增加組件開發(fā)人員的語句復(fù)雜性，也沒有任何不必要的運行時開銷。但是，如果恰好遇列舉出來得首位不是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;
- }
我會禁用掉稀奇古怪的默認參數(shù)。假定 IsInspectable 返回的是 true，我需要找到***個IInspectable-based 接口：
- 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>
- {
- };
實現(xiàn)類的模板，可以確保編譯器能生成更高效的代碼，不管 IHen、Hen2 來自 IInspectable 還是 IIUnknown （或者其他接口）?，F(xiàn)在，我可以***實現(xiàn) QueryInterface 的遞歸部分，以及任何追加的接口，例如上面例子中的 IHen2。BaseQueryInterface 是靠調(diào)用 FindInterface 函數(shù)模板結(jié)束的：
- 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);
- }
注意，我調(diào)用這個FindInterface函數(shù)模板，大致等同于我原來調(diào)用的BaseQueryInterface，在這個例子中，我向它傳遞接口的其余部分。我特意再次擴大參數(shù)包,這樣它可以在列表的其余部分識別***接口。但會提示一個故障。由于模板參數(shù)包不是以函數(shù)實參來擴展的，這可能會變得棘手，編程語言寫不出來我想要的。更多的時候，這種“遞歸的”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);
- }
它會從模板參數(shù)的其余部分中分離，如果有匹配就返回調(diào)整過的接口指針。另外，它也會調(diào)用自己，直到list取完。當我籠統(tǒng)地提及編譯期遞歸時，重要的是要注意這個函數(shù)模板，以及其他類似的實現(xiàn)類模板的例子，在技術(shù)上遞歸，而不是在編譯期。每個函數(shù)模板的實例調(diào)用不同的函數(shù)模板的實例。例如，F(xiàn)indInterface<IHen, IHen2> 調(diào)用 FindInterface<IHen2>， FindInterface<IHen2>調(diào)用 FindInterface<>。為了讓它遞歸， FindInterface<IHen, IHen2>不需要調(diào)用FindInterface<IHen, IHen2>。
#p#
盡管如此，還是要記住，這樣的“遞歸”發(fā)生在編譯時，它就像你自己手寫的一條條if語句。但是，現(xiàn)在，我遇到麻煩了。這個序列如何終止呢？當然是當模板參數(shù)列表為空的時候。這個問題在于C++已經(jīng)定義了空模板參數(shù)列表的含義:
- template <>
- void * FindInterface(GUID const &) noexcept
- {
- return nullptr;
- }
這幾乎是正確的，但是編譯器會提示你，函數(shù)模板在這個特化中無法使用。同時，如果我不提供終止函數(shù)，當參數(shù)包為空的時候，編譯器將無法編譯最終的調(diào)用。這不是函數(shù)重載的情況，因為參數(shù)列表依舊是相同的。幸運的是，解決方案非常簡單。我可以通過提供一個無名的默認參數(shù)，來避免終止函數(shù)看起來像一個特化:
- template <int = 0>
- void * FindInterface(GUID const &) noexcept
- {
- return nullptr;
- }
編譯器樂于此，同時，如果請求一個不支持的接口，終止函數(shù)會簡單的返回一個空指針，同時虛函數(shù)QueryInterface將返回E_NOINTERFACE錯誤碼。對IUnknown而言，這考慮得很周到。如果你所關(guān)心的是經(jīng)典的COM，你可以安全的停在那里，因為那就是你所需要的所有內(nèi)容。關(guān)于這點，可以反復(fù)的操作，編譯器將優(yōu)化QueryInterface的實現(xiàn)，其間使用各種各樣的“遞歸的”函數(shù)調(diào)用和常量表達式，代碼至少和你手工寫的一樣好。對于IInspectable而言，同樣的方式也可以實現(xiàn)。
對于Windows 運行時類，實現(xiàn)IInspectable會增加額外的復(fù)雜度。這個接口并非是和IUnknown一樣的基礎(chǔ)性接口，它提供了一些不確定的工具的集合，而IUnknown則提供了絕對基礎(chǔ)的函數(shù)。關(guān)于此，我會為以后的文章留下一個討論，并聚焦于支持任意Windows運行時類的高效和現(xiàn)代的C++實現(xiàn)。首先，我會避開GetRuntimeClassName和GetTrustLevel虛函數(shù)。實現(xiàn)這兩個方法相對而言微不足道，同時由于極少使用，所以它們的實現(xiàn)可以簡單搪塞一下。GetRunTimeClassName方法，需要返回這個對象所代表的運行時類的完整名字的字符串。我將把這留給類自身去完成，決定是否去這樣做。實現(xiàn)類模板可以簡單地返回E_NOTIMPL，用來表明此方法并未實現(xiàn):
- HRESULT __stdcall GetRuntimeClassName(HSTRING * name) noexcept
- {
- *name = nullptr;
- return E_NOTIMPL;
- }
同樣的，GetTrustLevel 方法也會簡單返回枚舉類型的常量:
- HRESULT __stdcall GetTrustLevel(TrustLevel * trustLevel) noexcept
- {
- *trustLevel = BaseTrust;
- return S_OK;
- }
需要注意的是，我并沒有顯示的標記這些IInspectable方法為虛函數(shù)。避免聲明為虛函數(shù)，是為了讓編譯器剔除這些函數(shù)，COM類無需真正的實現(xiàn)任何 IInspectable 接口?，F(xiàn)在，我將注意力轉(zhuǎn)移到IInspectable GetIids 方法。這比 QueryInterface 更容易產(chǎn)生錯誤。盡管它的實現(xiàn)不是那么嚴格，但是一個高效的編譯器生成的實現(xiàn)也是可取的。GetIids 返回一個動態(tài)分配的 GUID 數(shù)組。每個 GUID 代表一個對象要實現(xiàn)的接口。起初你可能會認為，這只是對象通過 QueryInterface 所支持的一個簡單的聲明，但是那只在表面上看是正確的。GetIids 方法可能會保留一些接口而不公開。不管怎樣，我會以基本定義作為開始：
- HRESULT __stdcall GetIids(unsigned long * count,
- GUID ** array) noexcept
- {
- *count = 0;
- *array = nullptr;
***個參數(shù)指向調(diào)用者提供的變量，其中 GetIids 方法必須設(shè)置它為結(jié)果數(shù)組中的接口數(shù)目。第二個參數(shù)指向一個 GUID 數(shù)組，同時也表示著這里的實現(xiàn)是如何將動態(tài)分配的數(shù)組返回給調(diào)用者的。此處，我清除了這兩者參數(shù)，只是為了安全起見?，F(xiàn)在我需要決定這個類實現(xiàn)多少個接口。我想說的是，使用 sizeof 操作符，它可以確定這個參數(shù)包的大小，如下:
- unsigned const size = sizeof ... (Interfaces);
這相當方便，同時，編譯器也會報告參數(shù)包拓展后要展現(xiàn)的模板參數(shù)的數(shù)目。這也是一個有效的常量表達式，它會在編譯時產(chǎn)生一個值。我之前略為提及的，這無法實現(xiàn)的原因是，GetIids的實現(xiàn)會保留一些他們不愿和其他人共享的接口，這相當普遍。這些接口被稱為隱含接口。任何人都可以通過QueryInterface來查詢它們，但是GetIids不會告知這些接口是可用的。這樣，我需要為排除了隱含接口的可變sizeof操作符，提供一個編譯時的替代品。同時，我需要提供某種方式來聲明和標識這些隱含接口。我以后者作為開始。對于組件開發(fā)人員，我希望讓實現(xiàn)類變得盡可能簡單，這樣就需要一個不太引人注意的技巧。我簡單的提供一個Cloaked類模板，用來“修飾”任意的隱含接口:
- template <typename Interface>
- struct Cloaked : Interface {};
然后，我決定在類Hen上實現(xiàn)一個特別的"IHenNative"接口，并非所有的使用者都知道它的存在:
- class Hen : public Implements<IHen, IHen2, Cloaked<IHenNative>>
- {
- };
由于Cloaked類模板繼承自它的模板參數(shù)，所以已存的QueryInterface實現(xiàn)可以繼續(xù)無縫工作。我已經(jīng)增加了一點額外的編譯時的類型信息，現(xiàn)在我可以查詢它們。由此，我會定義一個IsCloaked類型，這樣，我就可以很容易的查詢?nèi)我饨涌谝耘袛嗨欠癖浑[藏:
- template <typename Interface>
- struct IsCloaked : std::false_type {};
- template <typename Interface>
- struct IsCloaked<Cloaked<Interface>> : std::true_type {};
現(xiàn)在，我可以使用一個遞歸的可變函數(shù)模板，來計算未隱藏的接口數(shù)目:
- template <typename First, typename ... Rest>
- constexpr unsigned CounInterfaces() noexcept
- {
- return !IsCloaked<First>::value + CounInterfaces<Rest ...>();
- }
當然，我需要一個終止函數(shù)，可以簡單的返回0:
- template <int = 0>
- constexpr unsigned CounInterfaces() noexcept
- {
- return 0;
- }
使用現(xiàn)代C++在編譯時進行算術(shù)計算的強大能力令人目瞪口呆，同時也簡單的令人驚嘆?，F(xiàn)在我通過請求數(shù)量來繼續(xù)完善GetIids的實現(xiàn):
- unsigned const localCount = CounInterfaces<Interfaces ...>();
一個不太圓滿的地方是，編譯器對常量表達式的支持還不是很成熟。盡管，這毫無疑問是一個常量表達式，但是編譯器卻不會如此看待constexpr成員函數(shù)。理想情況下，我可以標識CountInterfaces函數(shù)模板為constexpr，同時結(jié)果表達式也將是一個常量表達式，但是，編譯器不會這認為。另一方面，毋庸置疑，編譯器會優(yōu)化這段代碼?，F(xiàn)在，不管是什么原因，如果CountInterfaces沒有找到隱含接口，GetIids會簡單的返回成功，因為結(jié)果數(shù)組會為空:
- if (0 == localCount)
- {
- return S_OK;
- }
同樣的，這也是一個有效的常量表達式，編譯器會無需任何條件的生成代碼。換句話說，如果沒有未隱藏的接口，剩下的代碼會簡單的從實現(xiàn)中刪除。否則，代碼的實現(xiàn)，會強制要求使用傳統(tǒng)的COM分配器，分配一個合理大小的GUID數(shù)組:
- GUID * localArray = static_cast<GUID *>(CoTaskMemAlloc(sizeof(GUID) * localCount));
當然，這可能失敗，在這種情況下，我簡單的返回合適的HRESULT值:
- if (nullptr == localArray)
- {
- return E_OUTOFMEMORY;
- }
在這點上，GetIids準備好一個數(shù)組用來存放GUID。就像你所期待的那樣，我需要***一次枚舉接口，然后拷貝每個未隱藏的接口的GUID到這個數(shù)組之中。我將使用一組函數(shù)模板，就像我之前使用的那樣:
- template <int = 0>
- void CopyInterfaces(GUID *) noexcept {}
- template <typename First, typename ... Rest>
- void CopyInterfaces(GUID * ids) noexcept
- {
- }
這個可變模板（第二個函數(shù)）可以簡單的使用IsCloaked類型來決定，在增加指針之前，是否拷貝由First模板參數(shù)標識的接口的GUID。使用這種方式，可以遍歷數(shù)組，而無需記錄它包含多少個元素，或者它將寫入數(shù)組的哪個位置。我也禁止了關(guān)于常量表達式的警告:
- #pragma warning(push)
- #pragma warning(disable:4127) // Conditional expression is constant
- if (!IsCloaked<First>::value)
- {
- *ids++ = __uuidof(First);
- }
- #pragma warning(pop)
- CopyInterfaces<Rest ...>(ids);
如你所見，在***“遞歸”調(diào)用CopyInterfaces使用了可能增加的指針的值。我?guī)缀跬瓿闪?整個實現(xiàn)過程)。在返回給調(diào)用者之前，GetIids的實現(xiàn)可以通過調(diào)用CopyInterfaces來填充數(shù)組:
- CopyInterfaces<Interfaces ...>(localArray);
- *count = localCount;
- *array = localArray;
- return S_OK;
- }
對于Hen類來說，編譯器在它上面的所有操作都是透明的（它完全不知道這些操作）:
- class Hen : public Implements<IHen, IHen2, Cloaked<IHenNative>>
- {
- };
這就是一個好的庫所應(yīng)該有的樣子。Visual C++ 2015編譯器提供了Windows平臺下面對于標準C++的***支持。它允許C++開發(fā)者創(chuàng)建優(yōu)雅而高效的庫。這同樣支持使用標準C++開發(fā)Windows運行時組件，以及完全使用標準C++編寫的通用的Windows應(yīng)用程序。實現(xiàn)類模板僅僅只是現(xiàn)代C++針對Windows運行時的一個例子。(查看 moderncpp.com).
Kenny Kerr 是一位加拿大的開發(fā)者，同樣也是Pluralsight的作者，以及微軟的MVP。 它的博客是 kennykerr.ca。你可以關(guān)注他的Twitter賬號twitter.com/kennykerr。
多謝微軟的技術(shù)專家James McNellis審閱這篇文章。
英文原文：Visual C++ 2015 Brings Modern C++ to the Windows API
譯文鏈接：http://www.oschina.net/translate/visual-cpp-2015-brings-modern-cpp-to-to-windows-api
