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