Visual C++ 2015引入更新的C++特性有哪些

這篇文章主要講解了“Visual C++ 2015引入更新的C++特性有哪些”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“Visual C++ 2015引入更新的C++特性有哪些”吧！

Visual C++ 2015 是 C++ 團隊付出巨大努力將現代C++引入windows平臺的成果。在***的幾個發行版本里，VC++已經逐步添加了現代C++語言以及庫的特色，這些結合在一起會創造一個用于構建通用windows App和組件的絕對驚艷的開發環境。Visual C++2015建立在早期版本引入的驚人進步，提供了成熟的、支持大多數C++11特性以及C++ 2015子集的編譯器。你或許會懷疑編譯器支持的完整程度，公正地說，我認為他能支持大部分重要的語言特性，支持現代C++將會迎來windows 程序庫開發一片新的天地。這才是關鍵。只要編譯器支持一個高效優雅的庫的開發環境，開發者就能構建偉大的app和組件。

這里我不會讓你看一個枯燥的新特性列表，或者走馬觀花地看下它的功能，而是會帶你瀏覽下一些傳統情況下的復雜代碼現在如何讓人相當愉快書寫。當然，這得益于成熟的Visual C++編譯器。我將會向你展示windows的一些本質，在現在或將來API中實際上都是很重要的本質。

頗具諷刺意味的是,對于COM來說,C++已經足夠現代了.是的,我在談論組件對象模型(COM),多年以來,它一直是大多數Windows API的基石.同時,它也繼續作為Windows運行時的基石.COM無可爭辯的依附于C++的原始設計,借鑒了許多來自C++的二進制和語義約定,但是它從來都不夠優雅.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 Runtime 類需要實現的接口, 而且要方便開發者使用, 和編譯器訪問. 比如, 列出所有可用類型, 以便編譯器查詢, 甚至枚舉出相應的接口. 要是能實現這樣的功能, 也許就能讓編譯器生成 IUnknown QueryInterface 甚至 IInspectable GetIids 方法的代碼. 這兩個方法才是問題的關鍵. 按照傳統的觀念, 唯一的解決辦法涉及到語言擴展(language extensions), 萬惡的宏定義, 以及一堆難以維護的代碼.

兩種方法的實現, 都用到類需要實現的接口. 可變參數模板( variadic template)是***:

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

__declspec(novtable)拓展屬性可以防止構造函數和析構函數初始化抽象類的vfptr,這通常意味著減少大量的代碼.實現類模板包括一個模板參數包,這使它成為一個可變模板.一個參數包即一個模板參數接受任意數目的模板參數變量.但是在這種情況下,我描述的模板參數將只會在編譯時進行查詢.接口將不會出現在函數的參數列表之中.

這些參數的一個使用已經顯而易見.參數包拓展后成為公共基礎類的參數列表.當然,我仍然有責任到***實現這些虛函數,但是此刻我會描述一個實現任意數目接口的一個具體類:

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

因為參數包拓展為指定基礎類的列表,所有它等同于下面我可能會寫出的代碼:

class Hen : public IHen, public IHen2  {  };

用這種方式結構化實現類模板的美妙之處在于,我現在可以,在實現類模板中,寫入各種樣版實現代碼,而Hen類的開發者則可以使用這種不唐突的抽象,同時大量忽略隱含的細節.

到目前為止,一切都很好.現在,我將考慮IUnknown的實現.我應該可以在實現類模板中完整的實現它,并提供編譯器現在所擁有的類型信息.IUnknown提供了對于COM類非常重要的兩種工具,就像氧氣和水對于人類一樣.***個可能簡單些的是引用計數,這也是COM對象跟蹤它們生命周期的方式.COM規定一種侵入式的引用計數,它借助于每個對象,統計多少個外部引用存在,來負責管理自己的生命周期.這與智能指針,如C++ 11的shared_ptr類,的引用計數恰恰相反,智能指針對象并不知道它的共享關系.你可能會爭論這兩種方式的優缺點.但是,實際上COM的方法通常更高效,這也是COM的工作方式,你必須處理它.如果沒有其它的,你很可能會同意這點,在shared_ptr里面包裝一個COM接口會是一件極不友好的事情!

我將以只有運行時的開銷作為開始,它是通過實現類模板介紹的:

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

默認構造函數并不是真正的開銷所在,它只是簡單的確保最終的構造函數--它將初始化引用計數--為protected而不是public的.引用計數和虛構造函數都是protected的.讓派生類訪問引用計數,是為了允許更復雜的類組合.大多數類可以簡單的忽略它,但是需要注意的是,我正初始化引用計數為1.這和通常建議初始化引用計數為0,形成鮮明的對比,因為此時并沒有處理引用.這個方式在ATL中非常流行,明顯受到Don Box的COM本質論的影響,但是這是非常有問題的,ATL的源代碼的研究可以作為佐證.開始于這個假設,即引用的所有權將會立即由調用者獲得,或者依附于一個提供更少錯誤構造處理的智能指針.

虛析構函數提供了很大的便利性,它允許實現類模板實現引用計數,而不是強制實現類本身來提供實現.另一個選項,是使用奇特的遞歸模板模式(Curiously Recurring Template Pattern)來避免使用虛函數.通常我會選擇這個方法,但是它會稍微增加抽象的復雜性,同時,因為COM類本身有一個vtable,所以這里也沒有什么理由去避免使用虛函數.有了這些基本類型之后,在實現類模板中實現AddRef和Release將會變得非常簡單.首先,AddRef方法可以簡單的使用InterlockedIncrement來增加引用計數:

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

這不言自明.不要想出某些復雜的方法,通過使用C++的加減操作符來有條件的替換InterlockedIncrement和InterlockedDecrement函數.ATL通過極大的增加復雜性去做這個嘗試.如果你考慮效率,寧可為避免調用AddRef和Release產生謬誤而多花心思.同樣的,現代C++增加了對move語義的支持,以及增加轉移引用所有權的能力.現在,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編寫的<<COM本質論>>(Addison-Wesley Professional，1998)一書中，閱讀關于實現你自己的IUnknown的奇妙的和不可思議的方法。需要注意的是，雖然這是一本關于COM的優秀書籍，但是它是基于C++98的，并沒有呈現出任何現代C++的特征。為了節省時間，我假定你已經熟悉了QueryInterface的實現過程，并集中于如何用現代C++實現它。下面是虛函數本身:

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

給定一個GUID用來標識一個特別的接口之后，QueryInterface應該來決定一個對象是否實現了需要的接口。如果實現了，它必須減少這個對象的引用計數，同時通過外部參數來返回所需的接口指針。如果沒有實現，它必須返回一個空指針。因此，我將以一個粗略的輪廓來作為開始:

*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由接口指針再次調用，用來支持某種極少的而又允許的類組合場景。這些不受實現類模板的顯式支持，但是我情愿在這里做一個表率。重要的是，記住引用計數操作是面向接口的，而不是面向對象的。你不能 簡單的，在屬于一個對象的任意接口上面，調用AddRef或者Release。你必須依賴COM規則來管理對象，否則你會冒險引入以不可思議的方式崩潰的非法代碼。

但是我如何得知，請求的GUID是否就代表著類想要實現的接口呢？我需要回到實現類模板收集的類型信息的地方，其中類型信息通過它的模板參數包來收集。請記住，我的目標是準許編譯器為我實現它。我希望最終代碼，和我手寫的一樣高效，甚至更好。我會通過可變函數模板集合來進行查詢，函數模板自身包括模板參數包。我將以BaseQueryInterface函數模板作為開始:

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

BaseQueryInterface本質上是IUnknown QueryInterface的現代C++版本。它直接返回接口指針而不是HRESULT類型。空指針則表明失敗的情況。它接受單一函數參數，GUID標識著要查找的接口。更重要的是，我拓展了類模板參數包為完整模式，這樣，BaseQueryInterface函數就可以開始枚舉接口的處理過程。 起初你可能會認為，由于BaseQueryInterface是實現類模板的成員函數，所以它可以簡單直接的訪問接口的鏈表，但是我需要準許這個函數剝離鏈表中的***個接口，就像下面這樣:

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的多種接口不會引起歧義。cast只是校準了指針，讓類的vtable能找到正確的指針位置，因為所有vtable接口是以IUnknown的三個方法開始的，這非常符合邏輯。

而我不妨同樣添加IInspectable查詢的可選支持。IInspectable相當變態，在某種意義上，它是Windows運行時接口，因為每個Windows運行時預計編程語言（如 C# 和 JavaScript）必須直接來自IInspectable，而不僅僅只是IUnknown接口。相對于C++的工作方式和COM傳統的定義方式，以適應公共語言運行庫的方式實現對象和接口是不幸的事實。更不幸的是當對象組合的時候對性能的影響，我會在下文中討論。至于QueryInterface，我只需確保IInspectable能被查詢，它應該是一個Windows運行時類的實現，而不是一個簡單的典型COM類。雖然關于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的衍生接口。萬一實現典型的COM類不支持Windows運行時，就能確保隨后的對照是由編譯器排除的。這樣我可以無縫地支持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-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>  {  };

實現類的模板，可以確保編譯器能生成更高效的代碼，不管 IHen、Hen2 來自 IInspectable 還是 IIUnknown （或者其他接口）。現在，我可以***實現 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);  }

它會從模板參數的其余部分中分離，如果有匹配就返回調整過的接口指針。另外，它也會調用自己，直到list取完。當我籠統地提及編譯期遞歸時，重要的是要注意這個函數模板，以及其他類似的實現類模板的例子，在技術上遞歸，而不是在編譯期。每個函數模板的實例調用不同的函數模板的實例。例如，FindInterface<IHen, IHen2> 調用 FindInterface<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;  }

編譯器樂于此，同時，如果請求一個不支持的接口，終止函數會簡單的返回一個空指針，同時虛函數QueryInterface將返回E_NOINTERFACE錯誤碼。對IUnknown而言，這考慮得很周到。如果你所關心的是經典的COM，你可以安全的停在那里，因為那就是你所需要的所有內容。關于這點，可以反復的操作，編譯器將優化QueryInterface的實現，其間使用各種各樣的“遞歸的”函數調用和常量表達式，代碼至少和你手工寫的一樣好。對于IInspectable而言，同樣的方式也可以實現。

對于Windows 運行時類，實現IInspectable會增加額外的復雜度。這個接口并非是和IUnknown一樣的基礎性接口，它提供了一些不確定的工具的集合，而IUnknown則提供了絕對基礎的函數。關于此，我會為以后的文章留下一個討論，并聚焦于支持任意Windows運行時類的高效和現代的C++實現。首先，我會避開GetRuntimeClassName和GetTrustLevel虛函數。實現這兩個方法相對而言微不足道，同時由于極少使用，所以它們的實現可以簡單搪塞一下。GetRunTimeClassName方法，需要返回這個對象所代表的運行時類的完整名字的字符串。我將把這留給類自身去完成，決定是否去這樣做。實現類模板可以簡單地返回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 更容易產生錯誤。盡管它的實現不是那么嚴格，但是一個高效的編譯器生成的實現也是可取的。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 ...>();  }

當然，我需要一個終止函數，可以簡單的返回0:

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

使用現代C++在編譯時進行算術計算的強大能力令人目瞪口呆，同時也簡單的令人驚嘆。現在我通過請求數量來繼續完善GetIids的實現:

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

一個不太圓滿的地方是，編譯器對常量表達式的支持還不是很成熟。盡管，這毫無疑問是一個常量表達式，但是編譯器卻不會如此看待constexpr成員函數。理想情況下，我可以標識CountInterfaces函數模板為constexpr，同時結果表達式也將是一個常量表達式，但是，編譯器不會這認為。另一方面，毋庸置疑，編譯器會優化這段代碼。現在，不管是什么原因，如果CountInterfaces沒有找到隱含接口，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類型來決定，在增加指針之前，是否拷貝由First模板參數標識的接口的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引入更新的C++特性有哪些”的內容了，經過本文的學習后，相信大家對Visual C++ 2015引入更新的C++特性有哪些這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！