C++17 將會出現什么樣的變革？
這是我對當前在厄巴納舉行的C++委員會會議上的提案方面文章的第三部分。 這次是全部關于子組變革的，對這方面，我寫了很多文章，所以這僅僅是***部分。 前面那些部分是關于并發(concurrency)的, 然后 第二部分是關于核心，網絡，模型以及未定義行為方面的。
變革
這個提議已經在上一部分的反射部分提到了，在那里我們用反射和std::tie解決這個問題。這份提議想讓 = default變得合法; 對于所有的操作符 (>,<,==,!=, ...)。這些操作符仍然使用友元方法來實現，如下例所示：
- class Thing
- {
- int a, b;
- public:
- // ...
- friend bool operator<(const Thing&, const Thing&) = default;
- friend bool operator>(const Thing&, const Thing&) = default;
- friend bool operator<=(const Thing&, const Thing&) = default;
- friend bool operator>=(const Thing&, const Thing&) = default;
- };
因為已經提議過有范圍的for(ranged-for)循環,這個提議轉移到auto和默認類型.如果沒有提供類型,它也希望,在其它語句中,引進或采用有范圍的for的語法,使之合法,例如if語句:
- std::weak_ptr<foo> wp;
- if(x: wp.lock())
對于C++來說,這是一個巨大的改變,并且不是每個人都喜歡它,特別地,編譯器的創建者不得不處理這所波及的范圍.然而,如果委員會認可了下個版本的有范圍的for循環,那么在其他C++控制結構,如if,while,for等,中允許同樣的語法也就說得通了.
這篇文章對應的是N4074,它爭論提議的變化內容,即讓{expr}顯式的返回是錯誤的,因為顯式的決不應該是隱式的.關于草案中的更多細節,作者甚至給出了一個例子,說N4074提案可能導致未定義的行為.
作者提供了很好的概述:
| 如果足夠仔細,我們可以創建本質上無缺陷的庫.但是即便是***的庫,只要使用不當,都可能產生災難性的的后果.運行時按規定校驗的實際應用:當函數調用時,檢測前綴條件的過程,有助于在早期測試中,發現誤用的情況.同時也有助于提升開發速度,增強軟件健壯性.將按規定校驗拓展為開發階段而不僅僅是早期測試階段,將帶來更多長遠的益處. |
作者再一次提供了很好的概述:
| 內聯函數為對外無法暴露對象的接口,提供了合適的行為.盡管是不自然的樣版,通常還是會鼓勵用戶使用它們來包裝全局變量.其它的變通方法包括類的靜態數據成員,枚舉,宏和變量模板,所有這些都有奇怪的語法或缺陷,限制了適用性.這個提議在變量定義上面指定了inline標識符,這意味著在語義上類似于內聯函數的評估和鏈接.更通用的,這為命名值或非持續性變量提供了一種工具,它可以替代或補充 各種各樣的變通方法. |
當前對于易拷貝類型(trivially copyable type)的定義有一個缺陷:它對于不可訪問的/刪除的 拷貝/移動 構造函數和賦值操作符同樣有效.一個易拷貝對象也可以通過使用std::memcpy來拷貝,特別是當有一個易拷貝對象數組的時候,這在性能上更優.然而,對于一個刪除的/不可訪問的 拷貝/移動 構造函數或者賦值操作符,這樣做是不明智的.作者提議更新標準里面的措辭,并提高特性,讓std::is_trivially_copyable針對不可訪問的/刪除的 拷貝/移動 構造函數和操作符返回錯誤.
同樣的,這篇文章也有很好的概述:
| 一些類只在某些上下文中工作: 作用域守護(scope guard)作為子表達式通常是沒有用處的,表達式模板占位符作為局部變量也會出現問題.一個沒有使用的函數的結果可能意味著調用者會使用不同的協議,如std::async.這個提議拓展了類的聲明來阻止這類錯誤,并增加了通過類型替換自動解決它們的技術,例如一個表達式模板的值類型.另外,不可移動的對象的生成變得更加容易處理.
增加的功能包括"自動評估"提議里面提到的.這個提議更具表現力,可以更廣泛的應用,并且易于接受和使用. |
N4150 - 別名集合屬性: 針對C++中restrict一樣的別名語義
這個提議想增加restrict修飾符到C++，因為它已經存在于C99之中，同時,一些編譯器已經提供了restrict作為一個C++拓展。由于目前沒有定義restrict修飾符，作者尋求定義如何正確的使用它，特別是在C++ 11中像lambda一樣的特性。
這篇文章想提高std::uncaught_exception的可用性：
| 函數 int std::uncaught_exceptions() 返回了異常對象的數目,這些對象已經初始化,并被拋出或者被重新拋出,但是沒有激活任何處理程序. |
這個提議想讓assert(斷言)成為語言結構,而不是一個宏定義:
| assert宏定義從未表現得像一個真正的函數,在可以預見的未來,它將更像是一個操作符.在C中宏定義的表現方式,阻止了生產模式下的優化,但是在調試模式下卻允許產生任意的副作用.增加assert作為一個關鍵字和內置的操作符將產生益處,而不會存在任何副作用. |
這篇文章分析了如何在C++中支持契約式編程(contract programming)風格的特性.它嘗試著提供一個概況,關于如何在編譯時而不是運行時檢查的時候支持契約.作者定義了文檔的范圍,如下:
鑒于[N1962] 是一篇關于在C++之中增加契約式編程支持的相當完整的提議,這個文檔提供的是問題范圍,而不是一個特定的提議.我們集中于確認期望值,潛在的實現困難以及代價.
我們知道的其它契約式編程提議 — [N4075], [N4110] — 建立在一個假設之上.即前置條件的支持,必須以提供某種形式之下:在函數調用之前評估前置條件,偶爾取消前置條件的評估以及安裝未履行契約的處理程序.在這篇文章中,我們不會想當然的做這種假設.運行時支持只是我們分析范圍的一個子集.我們更細致的探索了一個可選方案:集中于靜態分析.
作為正式的通用引用, 類型T&& 總是右值(r-value)引用,除了作為模板參數或者使用了auto關鍵字。技術上仍然是右值引用，但是在這種情況下，表現上是非常不同。到目前為止,標準不識別這點，作者想介紹這個術語前向引用(forwarding reference)，關于在模板和auto關鍵字之中的右值引用。
成員函數的調用語法是x.f() 或者 x->f()，而非成員函數則是f(x).這在泛型編程代碼中會是一個問題，因為沒有統一的調用語法，而泛型編程代碼必須決定是調用成員函數還是非成員函數。
為了解決這個問題，作者提議允許使用語法x./->f()來調用自由函數,如果函數的***個參數是x的指針或者引用。這也很好的滿足C的用法，當函數***個指針參數是一個結構體的時候。作者使用FILE*和fseek作為例子。
當前,std::initializer_list不是可移動的,它是在移動語義變得重要之前設計的.同時,那個時候只提供拷貝語義看起來是足夠的,但是今天的情況已經發生了變化.作者提議一個模板化版本的std::intializer_list,它繼承于非右值intializer_list類型:
- template< typename T >
- struct initializer_list< T && >
- : initializer_list< T > {
這個構造實現了所有權和移動語義.
N4172 - 命名參數
命名參數的語法看起來和提議中的 "有范圍的for(ranged-for)循環" 類似。但是在近似（幾乎一樣）的語法表達下面，兩者有不同的意義。在一個函數調用過程中，你可以像下面例子中這樣對命名參數賦值：
- void foo(int x, int y, int z);
- foo(40,z: 30, y:20);
在這個例子里面的函數調用過程中，參數z的值是30， 參數x的值是40。另外，非命名參數不能放在命名參數之后。
同樣的,這篇文章也有很好的概述:
| 這個提議允許用戶定義點操作符(操作符.()),這樣我們可以提供"智能引用"類似于"智能指針".這個提議的要點在于,如果類Ref定義了操作符.(),那么默認在Ref對象上的每個操作都在操作符.()的結果之前.不管怎樣,顯式聲明為Ref成員函數的操作,應用到Ref對象上時不需要前置.程序員可以通過聲明操作符.()為private,來阻止指向一個引用對象的指針"滲透"到更大的程序之中. |
N4174 - 調用語法: x.f(y) vs. f(x,y)
這個很像N4165 - 統一調用語法.簡單的描述:
| 基本的建議是定義x.f(y)和f(x,y)是等價的.另外,為了增加兼容性和模塊性,我建議探索,當查詢可調用成員函數(或函數對象)時,忽略不可調用和不可訪問的成員函數的可能性,. |
這份文檔廣泛的討論了在C++中預設的比較該是什么樣子，以及它能夠將比較運算符設置為默認值有什么意義。本文和N4126有很大關聯，同時也與N4239相對應。
N4176 - 對比較的思考
Bjarne總結了下關于預設比較的討論：
| 這是一份摘錄了系統預設比較草稿的部分討論的摘要。它提出了許多提議并且根據一系列標準做了比較。我將會對關于比較標準的選擇有關的評論尤其感興趣（故意的雙關語）。 |
原文鏈接：http://www.oschina.net/translate/where-will-evolution-lead-cpp17
