1. 廢話少說為什么std::ranges值得你花一個下午搞明白先拋個場景。你寫了一段代碼要把一個vectorint里的偶數(shù)挑出來、翻倍、再求和。傳統(tǒng)寫法長這樣std::vectorint v{1, 2, 3, 4, 5, 6, 7, 8}; std::vectorint evens; std::copy_if(v.begin(), v.end(), std::back_inserter(evens), [](int n) { return n % 2 0; }); std::vectorint doubled; std::transform(evens.begin(), evens.end(), std::back_inserter(doubled), [](int n) { return n * 2; }); auto sum std::accumulate(doubled.begin(), doubled.end(), 0);夠直白但問題也很明顯中途多了兩個臨時容器代碼被迭代器對begin()和end()撕成了一截一截讀起來得手動把三段拼進腦子里。而用 C20 的std::ranges寫同一個邏輯auto sum std::ranges::fold_left( v | std::views::filter([](int n) { return n % 2 0; }) | std::views::transform([](int n) { return n * 2; }), 0, std::plus());一行管道把篩選→變換→折疊串成了自然語言式的鏈路沒有中間容器沒有迭代器對。這就是std::ranges系統(tǒng)最直觀的價值讓算法更貼近人類表達同時干掉大量手寫迭代器代碼。這篇我想聊的不是照抄文檔而是在實際項目里把std::ranges用起來之后我理解的這整套系統(tǒng)是怎么設(shè)計的、有哪些真正好用的點、哪些性能坑要繞開。適合三類人看剛學完 C 基礎(chǔ)、聽說過 ranges 但不知道從哪下手的寫了好幾年 STL 算法、覺得begin/end寫煩了的老手以及負責團隊代碼規(guī)范、想評估要不要引入 ranges 的技術(shù)負責人。2. 從迭代器對到范圍這套系統(tǒng)到底改了什么2.1 核心不是管道符是概念上的范圍很多人第一次看到std::ranges就盯著|操作符看覺得這是新語法。其實管道符只是語法糖真正的核心是把范圍Range提升為一等公民。傳統(tǒng) STL 算法有個根深蒂固的設(shè)計算法操作的是迭代器對也就是從哪開始和到哪結(jié)束。這帶來了一個長期被吐槽的毛病——算法和容器之間永遠隔著一層。你要排序一個vector寫的是sort(v.begin(), v.end())而不是sort(v)。該怎么解釋這個轉(zhuǎn)變呢?？梢赃@樣想傳統(tǒng)算法像拆快遞你遞過去的是繩子這頭和繩子那頭距離多少、中間有沒有纏著膠帶算法一概不管而 ranges 改成了你把一整團繩子遞過去它自己知道從哪頭開始、到哪頭結(jié)束、中間經(jīng)過什么結(jié)構(gòu)。這個抽象可不是僅僅是少敲幾個字母。它意味著算法可以直接吃容器ranges::sort(v)而不是sort(v.begin(), v.end())。算法可以吃視圖viewfilter、transform運算得到的東西也是一個范圍可以繼續(xù)傳給別的算法。算法可以吃哨兵sentinel范圍的結(jié)尾不必非得是指向最后一個元素之后的迭代器可以是任何能判斷是否到達末尾的謂詞對象。這第三點在日常代碼里最不起眼但其實是整套系統(tǒng)里最深刻的設(shè)計之一。以前你處理以 \0 結(jié)尾的字符串或者讀文件直到某個標記得先把它們轉(zhuǎn)成有end()的容器或者硬寫循環(huán)判斷?，F(xiàn)在你只要定義恰當?shù)念愋偷? 哨兵算法直接就能在上限未定的范圍上工作。后面實戰(zhàn)部分我會給個例子。2.2 三個支柱視圖、算法、適配器的分工std::ranges不是一個大一統(tǒng)庫而是三塊咬合在一起的部分組件作用常見例子std::ranges::xxx算法操作一個范圍對象的算法sort、transform、filter、find_if、fold_leftstd::views::xxx視圖適配器把范圍變換成新范圍延遲計算filter、transform、take、drop、reverse、join范圍概念與工具定義什么樣的類型是范圍、提供輔助工具std::ranges::range、std::views::all、std::ranges::size、std::ranges::subrange三個東西分工非常明確視圖管怎么變換數(shù)據(jù)算法管怎么處理數(shù)據(jù)概念管什么樣的對象能參與這套體系。三者獨立演進又互相咬合這是整個設(shè)計最講究的地方。打個比方視圖是裝修方案變換瓷磚換成木地板算法是驗收標準檢查地面是否平整概念是房屋基本條件必須有四面墻和屋頂否則免談。2.3 懶惰求值為什么view不會復制數(shù)據(jù)視圖適配器最核心的行為特征是懶惰求值——普通算法是你調(diào)用它它立刻把所有元素處理完而視圖是你調(diào)用它它只是搭好了一條流水線真正處理要等你去消費元素的那一刻。用filter舉例auto evens v | std::views::filter([](int n) { return n % 2 0; });執(zhí)行這一行的時候filter并沒有遍歷v沒有把偶數(shù)挑出來存進一個新容器甚至沒有調(diào)用一次 lambda。它只是創(chuàng)建了一個視圖對象這個對象內(nèi)部保存了底層范圍v的引用和篩選謂詞。等你什么時候for (int n : evens)或把evens傳給某個算法時它才開始一個接一個地檢查元素。這個設(shè)計的好處有兩個零拷貝、零分配。你永遠不需要把中間結(jié)果存下來。對于動輒幾十萬條記錄的日志文件、傳感器時間序列這一點直接決定了內(nèi)存占用是 O(n) 還是 O(1)?？梢詿o限拼接。比如| take(5)從無限序列如輸入流、隨機數(shù)生成器里取前 5 個你不需要先生成完整序列。用傳統(tǒng) STL 你根本沒法優(yōu)雅地表示無限序列因為迭代器對要求序列必須有盡頭而 ranges 的視圖配上哨兵可以表達無窮盡的范圍。我剛開始也被懶惰這個特性繞暈過總覺得怎么它不干活。后來我用一個類比搞明白了視圖是電視遙控器上的直播畫面——你按下頻道1按鈕屏幕并不會立刻把未來一天的所有節(jié)目都緩存下來它只是把頻道指針調(diào)了一下真正播放是每秒都在發(fā)生的。視圖就是調(diào)整頻道指針那一下真正播放是你遍歷元素那一刻。3. 先看效果再聊原理一個真實腳本被 ranges 改寫的全過程3.1 改前的經(jīng)典寫法某次寫一個小工具要從一堆日志文本里篩出所有ERROR級別的行提取錯誤碼比如[E1001]這種格式按出現(xiàn)次數(shù)從高到低排序最后輸出 Top 3。先行代碼是這樣的很常見std::ifstream file(app.log); std::vectorstd::string errors; std::string line; while (std::getline(file, line)) { if (line.find(ERROR) ! std::string::npos) { errors.push_back(line); } } std::vectorstd::string codes; for (const auto e : errors) { auto pos e.find([); if (pos ! std::string::npos) { codes.push_back(e.substr(pos 1, 5)); } } std::mapstd::string, int counter; for (const auto c : codes) { counter[c]; } std::vectorstd::pairstd::string, int sorted(counter.begin(), counter.end()); std::sort(sorted.begin(), sorted.end(), [](const auto a, const auto b) { return a.second b.second; }); for (int i 0; i 3 i sorted.size(); i) { std::cout sorted[i].first sorted[i].second \n; }能跑但這里有多少次中間拷貝errors拷貝了所有 ERROR 行codes拷貝了提取出的錯誤碼sorted又從 map 拷了一份進 vector……這個腳本處理的日志只有幾百行無所謂但如果日志有幾 GB這種寫法會直接讓內(nèi)存爆掉。還有讀代碼的人要把五個循環(huán)串起來才能知道整體在做什么心智負擔不輕。3.2 改后的 ranges 版本用std::ranges重構(gòu)后長這樣std::ifstream file(app.log); std::string line; std::mapstd::string, int counter; for (auto input : std::ranges::istream_viewstd::string(file)) { if (auto pos input.find(ERROR); pos ! std::string::npos) { if (auto bracket input.find([); bracket ! std::string::npos) { counter[input.substr(bracket 1, 5)]; } } } std::vectorstd::pairstd::string, int sorted(counter.begin(), counter.end()); std::ranges::sort(sorted, std::greater{}, std::pairconst std::string, int::second); for (auto [code, count] : sorted | std::views::take(3)) { std::cout code count \n; }改動點逐個說明std::ranges::istream_viewstd::string(file)把文件流包裝成一個范圍每迭代一次讀入一行字符串。它依然是按需讀取不會預讀整個文件。兩個if嵌套代替了原來的errors和codes兩個中間 vector。注意 C17 引入的if (auto x ...; 條件)語法搭配使用作用域緊綁在一起變量生命周期更精確。排序直接用std::ranges::sort不再需要sorted.begin(), sorted.end()而是整個sorted。第四參數(shù)傳了一個投影projectionstd::pairconst std::string, int::second——這又是一個 ranges 帶來的好東西下面單獨說。輸出時用sorted | std::views::take(3)優(yōu)雅地控制只取前 3 個不需要手寫i 3 i sorted.size()這種邊界判斷。提示std::pairconst std::string, int::second這樣的寫法在部分編譯器上需要顯式指定成員指針類型dangling 風險很低。如果嫌難看也可以寫個 lambda[](const auto p) { return p.second; }。3.3 投影Projection這玩意兒是隱藏的寶貝上面解了ranges::sort的第四參數(shù)投影。它允許你在不創(chuàng)造臨時對的情況下告訴算法請按這個屬性的值來操作元素。以前你要按學生成績排序就得寫完整比較 lambdastd::sort(students.begin(), students.end(), [](const auto a, const auto b) { return a.score b.score; });用 rangesstd::ranges::sort(students, std::greater{}, Student::score);更妙的是投影不光能用于排序find_if、count、lower_bound等大量 ranges 算法都支持。比如查找第一個成績及格的學生auto it std::ranges::find_if(students, [](int s) { return s 60; }, Student::score);這里的 lambda 拿到的直接就是score的引用而不是整個Student對象。代碼意圖瞬間清晰我要找這么一個人他有一個 score 字段這個字段滿足某種條件。投影把取字段這個動作從比較謂詞里剝離出來讓每個關(guān)注點各管一攤。3.4 一個小插曲編譯器的版本要求入坑 ranges 之前先檢查編譯器。截至 2024 年初GCC 12、Clang 16、MSVC 19.31 對 ranges 的支持都比較完整。GCC 10/11 對一些 fancy 的視圖如views::enumerate、views::chunk要么缺失要么有 bug。我的建議是直接上 GCC 13 或 Clang 17省得被明明代碼照著 cppreference 抄的但編譯不過氣得摔鍵盤。std::ranges::fold_left是 C23 才進的要用的也得注意標準版本C20 時期可以用std::accumulate(r.begin(), r.end(), 0)替代雖然看著不夠帥但不影響邏輯。4. 容易翻車的幾個點views 的生命周期和 const 問題4.1 懸垂視圖Dangling View把臨時容器丟了就完蛋這是 ranges 新手最常踩的坑沒有之一?？催@段std::ranges::range auto get_even_view(std::vectorint v) { return v | std::views::filter([](int n) { return n % 2 0; }); } auto main() - int { auto evens get_even_view(std::vectorint{1, 2, 3, 4}); // 災難底層臨時 vector 已經(jīng)被銷毀evens 里保存的是懸空引用 }視圖默認是引用語義——它保存底層范圍的引用或迭代器自己不擁有數(shù)據(jù)。第一行那個臨時std::vectorint在表達式結(jié)束后就析構(gòu)了而evens還傻乎乎地握著一個指向已滅亡容器的迭代器一行for (int x : evens)就是 undefined behavior輕則亂值重則段錯誤。這是 C 里老生常談的懸垂引用問題在 ranges 里的形態(tài)。解決的思路也一致不要讓視圖比底層數(shù)據(jù)活得更久。視圖的生命周期必須嵌套在容器的生命周期內(nèi)。如果非要返回一個擁有數(shù)據(jù)的視圖別用 filter/transform 這類引用視圖可以先拷成std::vector等具體容器再返回或者用自己的 RAII 類包一層。我之前在日志分析工具里就犯過這個錯。過濾器返回了一個局部范圍上的視圖函數(shù)一結(jié)束原先那個只讀打開的文件內(nèi)容緩沖區(qū)被回收整個視圖變成一堆野指針。從那以后凡是視圖要跨作用域傳遞我都額外加注釋提醒自己此處按引用持有底層對象。注意views::all、views::filter這類視圖絕不擁有數(shù)據(jù)而ranges::tostd::vector()C23是把范圍急切地物化成容器的正確姿勢——它真的把元素拷貝進去不再引用原范圍。4.2 const 正確性視圖和 const 容器一起用容易讓編譯器發(fā)飆簡單規(guī)則const容器的視圖只能用const謂詞來直接作用在元素上但很多可變的視圖如reverse、transform對const容器會拋出編譯錯誤或顯著限制。比如const std::vectorint v{1, 2, 3, 4}; auto rev v | std::views::reverse; // 在部分標準庫實現(xiàn)里這行會編譯失敗因為 reverse_view 的 begin() 非常量方法調(diào)用受限原因很微妙reverse_view::begin()返回其內(nèi)部迭代器該迭代器可能保存一個底層迭代器而底層迭代器在 const 容器里是 const_iterator正常應該能通過。但早期實現(xiàn)里reverse_view需要持有非 const 的 begin() 來滿足某些概念約束導致 const 范圍適配不佳。解決辦法很土把容器聲明為非 const 但語義上不修改或者在需要跨函數(shù)傳遞時顯式轉(zhuǎn)成std::views::all(v)再迭代。實際項目里最省心的是盡量保持容器非 const 傳給視圖只有在明確不會觸發(fā)視圖寫語義的地方才放心用 const。讀者可能會好奇為什么標準不把 const 這事兒完全做對。這里是客觀現(xiàn)實有些視圖比如iota_view、istream_view天生對是否可變迭代器敏感標準里對應的概念迭代器分類又保守導致你自查起來非常隱蔽。我的策略很簡單交付前用static_assert(std::ranges::rangedecltype(myView))檢查一遍基礎(chǔ)性質(zhì)再用編譯期的概念斷言去捕捉 const 相關(guān)錯誤剩下就交給 lint 工具了。4.3 迭代器類型太復雜auto 是你的朋友但不是全部視圖鏈一長begin()的返回類型就變成了一串嚇人的模板嵌套。別看不起編譯器輸出也別自己去手寫那個類型——一律用auto必要的時候用decltype或者 CTAD 來拿類型。auto chain v | std::views::filter(...) | std::views::transform(...) | std::views::take(10); auto it chain.begin(); // 別試圖手寫它的類型 auto first *it;一旦你需要用視圖的迭代器類型去聲明其他東西立即變成一大坨無法維護的std::ranges::iterator_t...。萬一標準庫更新類型名字一變你手寫的類型就崩了。所以寫 ranges 代碼的第一紀律任何迭代器型和視圖型交給類型推導絕不手寫。5. 從抄到造自建視圖組件理解 view_interface 基礎(chǔ)設(shè)施5.1 什么時候需要自寫視圖什么時候別寫std::views提供了官方適配器全家桶但我遇到固定模式反復出現(xiàn)在十幾個文件中時還是考慮封裝成自定義視圖。比如每 N 個元素歸一組取平均值或者處理一個 CSV 行把每列解析成結(jié)構(gòu)體——這些既不是標準庫覆蓋的行為又不想在業(yè)務(wù)代碼里到處擺 for 循環(huán)。但先別急著造輪子。自寫視圖的代價是你不僅要實現(xiàn)begin()/end()還要確保符合一堆概念view、input_range、forward_range……還要處理值語義、拷貝語義、迭代器的六大 typedef。標準庫里std::ranges::view_interface就是給你提供這些基礎(chǔ)設(shè)施的——只需要你在派生類里實現(xiàn)begin()和end()它就可以免費提供size()、empty()、operator[]等一大堆便捷成員函數(shù)。5.2 一個最簡單的自造視圖每隔一個元素取一個stride下面這個實現(xiàn)適合拿來當模板它生成一個每隔 step 個元素才產(chǎn)出一次的視圖template std::ranges::view V class stride_view : public std::ranges::view_interfacestride_viewV { private: V base_; std::ranges::range_difference_tV step_; std::ranges::iterator_tV current_; public: stride_view() default; stride_view(V base, std::ranges::range_difference_tV step) : base_(std::move(base)), step_(step) { current_ base_.begin(); } auto begin() { return current_; } auto end() { return base_.end(); } };光有begin/end還不夠迭代器的自增得實現(xiàn)跳步邏輯。我們可以用一個非常簡單的方案創(chuàng)建這個視圖時就把迭代器直接推進到合適的起始位置而begin()返回的迭代器自增時維護一個內(nèi)部計數(shù)器遇到step-1個元素就跳過、輸出第step個。完整實現(xiàn)代碼量不小不在這里全部展開。我想強調(diào)的是看官方 adapter 的源碼比如drop_view、take_view是學習自造視圖最快的路徑。它們在實現(xiàn)上都利用view_interface提供的腳手架代碼量其實很少。自造視圖的時候先把這些條件想清楚設(shè)計問題自查項底層是單向范圍還是雙向范圍這決定迭代器是輸入迭代器還是前向迭代器能支持哪些算法step 為 0 或負數(shù)的行為必須定義別讓 UB 溜進來視圖的拷貝是否拷貝底層范圍默認是淺拷貝符合語義即可end()返回值類型與begin()一致不一致就需要哨兵支持邊界處理麻煩是否滿足view概念必須是可拷貝構(gòu)造和析構(gòu)的且拷貝是 O(1)自造視圖最大的價值不是代碼復用而是讓你更深地理解視圖這個抽象的本質(zhì)——它必須輕、必須是引用語義、必須正確建模范圍的迭代能力和結(jié)束條件。5.3 性能面懶惰不等于免費但通常比臨時容器快很多人看完上面的內(nèi)容會有一個錯覺既然是懶惰求值那性能肯定永遠是最好的。真相是懶惰求值跳過的是分配內(nèi)存 拷貝元素的開銷但每次迭代元素時仍然可能多做幾次函數(shù)調(diào)用和分支判斷。比如前面的篩選偶數(shù)再翻倍例子。v | filter(偶數(shù)) | transform(翻倍)對于每個元素至少要經(jīng)歷 filter 謂詞的一次判定、transform 謂詞的一次調(diào)用。如果這兩種操作本身非常廉價就是幾次整數(shù)運算那傳統(tǒng)寫法兩個臨時 vector 三次循環(huán)相比 ranges 管道通常是差不多的開銷因為傳統(tǒng)寫法也做了同樣多次的謂詞調(diào)用而且多了分配和拷貝。真正讓 ranges 管道顯得慢的場景是錯誤地在一個億級元素的循環(huán)內(nèi)部每輪重復構(gòu)造同一串視圖鏈。視圖對象自身創(chuàng)建雖然便宜但在循環(huán)里反復創(chuàng)建、每次遍歷效率確實比直接在循環(huán)體外建好再復用差一點。好在標準實現(xiàn)通常把這些小對象優(yōu)化得很極致只要視圖不在最內(nèi)層循環(huán)里反復重新求值實際跑起來很難感覺到與手寫循環(huán)有數(shù)量級差異。我在生產(chǎn)環(huán)境做過一個簡單的 benchmark別太當真主要看數(shù)量級對一個 1000 萬元素整數(shù)數(shù)組做過濾偶數(shù) → 翻倍 → 累加手寫循環(huán) vs ranges 管道結(jié)果是手寫循環(huán)快 20~30%。理論上差的這些點主要來自函數(shù)無法內(nèi)聯(lián)當謂詞是無捕獲 lambda 時現(xiàn)代編譯器都能內(nèi)聯(lián)一旦用std::function或虛函數(shù)封裝就會暴跌。所以性能建議很直白小數(shù)據(jù)集或中數(shù)據(jù)集放心用 ranges代碼可讀性收益遠大于那百分之幾的性能差。大數(shù)據(jù)集 熱循環(huán)先用 ranges 寫清楚再針對性 benchmark如果確實慢手寫循環(huán)也不丟人。謂詞必須避免虛函數(shù)調(diào)用和std::function開銷。6. 我踩過的坑和團隊的磨合實錄前面講了不少應該怎么做這里換個角度講講實際項目中踩過的幾個真坑以及我們團隊從禁止用 ranges到默認用 ranges的態(tài)度轉(zhuǎn)變。6.1 模塊邊界處的類型爆炸有一陣子我對 ranges 上頭寫了一個庫內(nèi)部接口參數(shù)形如std::ranges::input_range auto r聲明得特別高級。結(jié)果其他同事接手時一臉茫然——這是啥能用 vector 嗎然后每個調(diào)用點都開始出現(xiàn)template typename R的模板函數(shù)模塊間接口從清晰的具名類型變成了一大堆泛型約束。編譯錯誤提示還特別難看一個概念沒滿足就刷出幾百行no matching function for call to ... constraints not satisfied。這件事給我的教訓是ranges 內(nèi)部的算法鏈可以盡情用但跨模塊公開 API 不要輕易給函數(shù)套模板。除非你是寫庫的否則公共接口老老實實用具體容器類型vector、span反而清晰可維護。泛型接口省下的那點代碼量會在可讀性和編譯速度上原樣還回來。6.2 藏在迭代器失效里的 bug你以為用了 ranges 就不會有迭代器失效了嗎天真。視圖只是把迭代器封裝了一層底層容器照樣可能被修改。最經(jīng)典的翻車現(xiàn)場std::vectorint v{1, 2, 3, 4, 5}; auto view v | std::views::filter([](int n) { return n % 2 0; }); v.push_back(6); // 向量的 push_back 可能使所有迭代器失效 for (int n : view) { // 未定義行為 std::cout n ; }filter_view的迭代器內(nèi)部存著v的迭代器也可能只存了一個 begin 迭代器其實它有個內(nèi)部緩存的 begin 迭代器push_back之后緩存里那個迭代器可能就指向懸空位置了。雖然標準并沒有規(guī)定filter_view一定要緩存 begin 迭代器但多數(shù)實現(xiàn)是緩存的所以這個坑幾乎必然觸發(fā)。這條讓我養(yǎng)成了習慣在同一個作用域內(nèi)視圖一旦創(chuàng)建底層容器就只讀不寫。往容器加元素、刪元素、擴容的操作一律放到視圖作用域之外或者干脆先完成容器修改再創(chuàng)建視圖。這不是 ranges 的設(shè)計缺陷這是所有基于迭代器的庫共有的約束——std::sort之后你還不是得小心迭代器失效。6.3 團隊引入 ranges 的節(jié)奏建議我不建議一步到位把所有代碼都改成 ranges 風格。那樣做的后果往往是一半人會用一半人看不懂code review 變成兩個人互相說服對方的辯論賽。更務(wù)實的路徑是分三步走先讓所有人熟悉ranges::sort、ranges::find_if這類單算法版把它們當作 STL 算法的提速版。不必引入管道符就能消滅海量begin()/end()。第二步統(tǒng)一引入views::filter和views::transform同時規(guī)定視圖只在函數(shù)內(nèi)部使用不得跨函數(shù)傳遞不得引用臨時對象。第三步再放開自由組合讓大家用管道組裝復雜邏輯但配 code review 檢查清單生命周期、迭代器失效、const 正確性。我見過不少團隊上來就鋪管道結(jié)果 bug 率上升、新人挫敗感強。逐步放開反而更穩(wěn)。另外強烈建議把編譯器和標準庫升級到版本列表里較新的那一檔否則你會踩到很多標準有但這版本沒修的坑。7. 值得進一步挖的角落哨兵、子范圍、生成器與 C23/26 的延續(xù)7.1 哨兵Sentinel范圍的另一種結(jié)束方式前面提到過ranges 允許結(jié)束標志不是迭代器而是哨兵。它的威力在實際代碼里體現(xiàn)在處理讀輸入直到某標記的場景。比如處理一個以-結(jié)尾的字符串數(shù)組。傳統(tǒng)寫法你得先數(shù)有多少個元素或者干脆規(guī)定end()是數(shù)組末尾。用哨兵你可以定義一個謂詞是否是終止標志然后把數(shù)組包裝成范圍struct not_dash_sentinel { const char* current; friend constexpr bool operator(const char* pos, not_dash_sentinel s) { return *pos -; // 到達 - 即視為結(jié)束 } }; const char content[] abc-def; std::string result(std::ranges::begin(content), not_dash_sentinel{content}); // result abc這個例子有點簡陋但思路很清楚定義范圍結(jié)束的標準可以是任何條件。這讓 ranges 能統(tǒng)一處理有限但長度未知的數(shù)據(jù)源。配合ranges::subrange使用可以在保留某段迭代器區(qū)間的同時不丟失邊界信息比裸存兩個迭代器安全多了。7.2 生成器視圖views::iota和自定義生成器std::views::iota(1, 100)生成一個從 1 到 99 的整數(shù)序列視圖。它沒有底層容器元素是按需生成的。更妙的是它沒有上界版本for (int i : std::views::iota(1) | std::views::take(10)) { std::cout i ; // 1 2 3 4 5 6 7 8 9 10 }這種生成器 適配器的組合是函數(shù)式風格的基石。讓它變成生產(chǎn)力的真正技巧是把隨機數(shù)引擎、時間戳、甚至命令行參數(shù)序列包裝成生成器。比如生成遞增時間戳auto current std::chrono::system_clock::now(); auto timestamps std::views::iota(0) | std::views::transform( [current](int offset) { return current std::chrono::seconds(offset); });然后你可以for (auto t : timestamps | take(10))。這在寫仿真、測試數(shù)據(jù)生成時非常順手。7.3 C23 和 C26 的延續(xù)單子操作、tovector、格式化輸出C23 為 ranges 補完了一部分舊標準缺失的適配器和工具std::ranges::tostd::vector()把視圖急切地物化成容器而且是真正的擁有數(shù)據(jù)。這幾年被無數(shù)人吐槽視圖不能轉(zhuǎn)容器的痛點終于解決。用法auto vec v | views::filter(...) | std::ranges::tostd::vector();std::views::enumerate給元素配上索引輸出。以前你得用一個計數(shù)器變量在循環(huán)里手動現(xiàn)在視圖自帶。std::views::zip把兩個范圍打包成元素對范圍處理兩個平行序列再也不用手寫索引對齊。std::views::chunk按固定大小分塊處理序列一口氣處理每 4 個一組求和這種邏輯。單子操作monadic operationsviews::transform配合std::optional可以寫類似鏈式調(diào)用的求值流C23 逐漸引入transform與and_then的視圖封裝代碼風格越來越接近函數(shù)式語言。C26 目前的草案還包含更復雜的視圖以及改進的 format 支持。我個人的感覺是ranges 的演進方向正在把 C 從必須先構(gòu)造完整數(shù)據(jù)結(jié)構(gòu)才能處理的老套路中徹底解放出來數(shù)據(jù)流式的處理方式逐漸成為主流。8. 給新手的一句實在話看到這里可能信息量有點大。我建議直接照著下面的路線動手用std::ranges::sort替換三個日常排序。用std::views::transform重寫一個從容器生成新容器的循環(huán)。找一個filter加transform加take組合的練習題做掉。試著給自己的某個范圍寫一個最簡單的自定義視圖。代碼編輯器里敲一遍比讀十篇博客都管用。真碰到編譯報錯別急著放棄概念約束的報錯通常背后都有一個具體的語義問題仔細看最前面幾行錯誤信息往往就能定位比如視圖生命周期問題、迭代器類型不匹配。我現(xiàn)在的經(jīng)驗是ranges 的報錯看著嚇人但九成情況下錯誤信息的第一行就指明了問題所在別被后面幾百行模板垃圾嚇退。這套系統(tǒng)確實有一定的學習曲線但它換來的是代碼表達力的大幅提升以及整個團隊在處理數(shù)據(jù)流這一層抽象上的共同語言。如果你在寫需要經(jīng)常處理集合、序列、數(shù)據(jù)管道的 C 代碼那么花一天時間入坑 ranges長期來看肯定不虧。