C++17 最新進展報告
C++標準委員會最近在夏威夷的科納召開了一次會議,大家可能關心***的進展,但是按照以往的情況,某些文件需要很久才會公開。會議進行的時候,大 家都在忙著修訂自己的文件,會議之后,大會會收集改好的文件,在幾周之后發布。但是這一次,委員會修改了他們的系統,所以得到早些版本的文件非常簡單,這些郵件就是公開的。
我從官方收集與組織了這些信息,沒有任何我個人的主觀評論。如果你想知道這次會議的主要內容,請閱讀下面的內容(我已經知道了絕大多數關于C++17庫的內容,但是要將其全部寫出來還是需要一定的時間)
C++17核心庫文件
-
P0001R1 棄用register關鍵字
-
P0002R1 bool類型不再支持++運算符
-
P0012R1 異常成為類型系統的一部分,第五版
-
P0061R1 支持__has_include
-
P0134R0 引入非靜態成員變量的拷貝構造函數//not sure
-
P0136R1 重寫繼承構造器(core issue 1941 et al)
-
P0160R0 刪除一元運算符的預設值//Wording for removing defaults for unary folds
C++17庫相關文件
-
P0004R1 棄用過時的iostreams的別名
-
P0006R0 采用基于標準庫規范的類型特征變量模板
-
P0092R1 優化
-
P0007R1 Constant View:一個::as_const 的輔助函數模板
-
P0156R0 可變的lock_guard (Rev. 3)
-
P0074R0 使std::owner_less更加靈活
-
P0013R1 邏輯運算符類型特征 (revision 1)
庫基本規范 第二版文件
-
N4531 替換std::rand,版本三
-
P0013R1 邏輯運算符類型特征 (revision 1)[C++17投票通過]
-
這些文件將會應用于N4529草案,然后進行擬議草案技術規范的投票。
并發規范
-
P0159R0 將會作為并發技術規范發布,屆時可能稍作改動。
并行規范 v2
-
N4505草案和P0155R0的”Task Block R5”負責這項工作。
網絡規范
-
P0112R1草案負責這想工作。
范圍規范
-
P0021R0草案負責這項工作。
核心主題
-
1274.常見的非終結符表達式和內嵌初始化列表
-
1391.非推導模板參數到參數類型的轉化
-
1722.lambda函數指針轉換函數應該不例外嗎?
-
1847.部分排序時聲明一致性
-
1863.拋出對象的類型應該支持std::current_exception()
-
1949.”sequenced after”代替”sequenced before”
-
1975.允許聲明異常類型
-
1981.隱式和顯式的上下文轉換
-
1990.decl-specifier-seq造成的歧義
-
2000.#include之外的頭文件名稱
-
2004.常亮表達式中有可變成員的變量
-
2006.Cv-qualified的void類型
-
2015.虛函數的odr-use
-
2016.類型轉換函數的描述中可能存在的歧義
-
2019.存儲時間描述中成員引用的省略
-
2024.依賴類型和未解包的參數包
-
2026.Zero-initialization和constexpr
-
2027.指定多個alignas的需求不明
-
2031.&&的不兼容
-
2052.模板參數推導vs重載操作符
-
2075.傳遞短初始化列表給數組引用參數
-
2101.對類型和值的依賴的錯誤說明
-
2120.數組作為標準布局類的***個非靜態成員變量
庫主題
-
1169.num_get不能和strto*完全兼容
-
2072.緩沖區容量定義不明確
-
2101.一些類型轉換可能產生非預期的類型
-
2111.處理異常時可能調用那些已經刪除的句柄?
-
2119.擴展int類型缺少哈希函數
-
2127.帶raw_storage_iterator的Move-construction
-
2133.重載逗號迭代器
-
2156.無序容器的reserve(n)保存的是n-1個元素
-
2218.容器如何使用allocator_traits::construct()不夠明確
-
2219.INVOKE-ing一個帶有reference_wrapper的指針作為對象表達式
-
2224.不活躍對象的狀態問題
-
2234.assert()應該允許在常亮表達式中使用
-
2244.關于basic_istream::seekg的issue
-
2250.Library Issue 2207中的Follow-up
-
2259.17.6.5.5規則中有關成員函數的問題
-
2273.regex_match的歧義
-
2336.is_trivially_constructible/is_trivially_assignable結果永遠是false
-
2353.std::next限制過度
-
2367.pair和tuple無參數時不兼容is_constructible
-
2380.<cstdlib>應該提供long ::abs(long) 和long long ::abs(long long)嗎?
-
2384.分配器的解除函數需要更好的規范
-
2385.function::assign分配器參數無意義
-
2435.reference_wrapper::operator()的標記應該是被刪除
-
2447.分配器和Volatile-qualified值類型
-
2462.std::ios_base::failure 被過度規范
-
2466.allocator_traits::max_size()默認表現是錯誤的
-
2469.map的[]操作符和unordered_map規則錯誤
-
2473.basic_filebuf對C文件的兼容
-
2476.scoped_allocator_adaptor是不可分配的
-
2477.std::vector::erase()和std::deque::erase()的不一致
-
2483.throw_with_nested()應該使用is_final
-
2484.rethrow_if_nested()是不可實現的
-
2485.常量tuple&&應該重載get()
-
2486.mem_fn()應該提供向前兼容
-
2487.bind()不應該是cv-overloaded, 而應該是const-overloaded
-
2489.mem_fn()應該是noexcept的
-
2492.明確comp的需求
-
2495.沒有類似異常安全元素的東西
Library Fundamentals TS v2 Issues
-
2494.[fund.ts.v2] ostream_joiner應該是noexcept的
-
2500.[fund.ts.v2] fundts.memory.smartptr.shared.obs/6 應該適用于cv-unqualified void
-
2515.[fund.ts.v2]observer_ptr的確定操作符不能匹配任何簡介
-
2517.[fund.ts.v2] 兩個propagate_const assignment 操作符返回不正確的類型
-
2526.[fund.ts]experimental::function::swap 條件不正確
更多信息
以上只是投票通過的部分記錄。每次的會議都會涉及很多工作,不會全都反映在文件上,比如,有關modules的熱烈討論文件中就沒有。雖然我幾乎花了所有的時間在庫工作組中,但是還是不能跟進所有的內容。最終版文件我會在Reddit分享各個模塊的進展。
本文作者可以回答大多數有關庫的問題,但是可能回復略有延遲。可以確定的是,庫的可用性提高了。看起來一切都像小貓一樣溫順可愛,但是如果你去看一 眼重載集合,就會發現這些模棱兩可的東西簡直是災難。LWG2451是作為標準庫定義的一個極好的例子,optional<string> opt_str = “meow”;現在還未實現。對于基本規范沒有什么問題,但是optional的ship-stopper不符合國際標準。在這次會議上,LWG意識到一 些issue影響到了variant,問題會牽扯到基本規范。當然了,會議會解決這些問題,你不必經歷這些痛苦。