1. 我為什么又回頭研究bind代碼里最不起眼的粘連劑搞C時(shí)間一長(zhǎng)你會(huì)發(fā)現(xiàn)真正讓代碼繞起來的往往不是那些宏大設(shè)計(jì)而是一堆不起眼的小工具。std::bind就是其中之一。最近接手的某調(diào)度模塊里回調(diào)參數(shù)七零八落有的回調(diào)接口固定三個(gè)參數(shù)但實(shí)際業(yè)務(wù)只關(guān)心其中兩個(gè)有的回調(diào)接口里需要先塞一個(gè)配置對(duì)象后續(xù)運(yùn)行時(shí)再傳具體事件。我不想為了配合回調(diào)去改老接口也不想在每個(gè)調(diào)用點(diǎn)都寫一坨樣板代碼于是又把bind撿起來重新捋了一遍。這篇文章就是把這次實(shí)操中的理解和踩坑記錄下來主要內(nèi)容圍繞C的std::bind函數(shù)它到底是什么、能解決什么問題、有哪些坑、什么時(shí)候該用它、什么時(shí)候應(yīng)該果斷換成lambda。先說結(jié)論std::bind本質(zhì)上做的是偏函數(shù)應(yīng)用——把某個(gè)可調(diào)用對(duì)象的部分參數(shù)先固定下來生成一個(gè)新的可調(diào)用對(duì)象剩下的參數(shù)留到真正調(diào)用時(shí)再填。這個(gè)概念如果覺得陌生想想訂餐就容易了你先點(diǎn)了主食飲料兩樣剩下辣度配送時(shí)間等取餐時(shí)再說。代碼里最常見的場(chǎng)景就是某個(gè)事件回調(diào)的簽名和你業(yè)務(wù)函數(shù)的簽名對(duì)不上你不想改底層接口也不想在每個(gè)注冊(cè)處包一層手寫lambda于是用bind把參數(shù)對(duì)齊。對(duì)我來說bind的價(jià)值有兩個(gè)層面。第一是懶它能讓我少寫好幾層轉(zhuǎn)發(fā)樣板代碼第二是柔它提供了一種延遲綁定的方式把函數(shù)和一部分參數(shù)當(dāng)作一個(gè)整體傳出去這讓模塊之間的組合自由度一下子高了很多。不過bind在社區(qū)里的口碑其實(shí)挺兩極分化的有人說它是C里最容易被濫用的小工具之一也有人覺得它比lambda更直白。這種分歧本身就有意思。我把bind徹底研究完之后發(fā)現(xiàn)爭(zhēng)議其實(shí)不是bind本身的問題而是用的人有沒有搞清楚它的存儲(chǔ)語義和適用邊界。下面我按自己的理解把bind從頭到尾拆開講。2. 語法拆解bind的幾種綁定姿勢(shì)和占位符的排列邏輯2.1 頭文件和最基礎(chǔ)的綁定常量實(shí)參提前固定使用std::bind之前需要包含functional頭文件。它的典型調(diào)用形式是這樣的#include functional int add(int a, int b) { return a b; } int main() { using namespace std::placeholders; auto add10 std::bind(add, 10, _1); int result add10(5); // 相當(dāng)于 add(10, 5)結(jié)果是 15 return 0; }這段代碼里std::bind(add, 10, _1)做的事情是把a(bǔ)dd函數(shù)的第一個(gè)參數(shù)固定為10第二個(gè)參數(shù)留空用占位符_1表示等調(diào)用add10時(shí)把傳入的第一個(gè)實(shí)參放到這個(gè)位置。最終add10可以像普通函數(shù)一樣被調(diào)用。這里有個(gè)細(xì)節(jié)需要記牢bind的返回值類型是一個(gè)實(shí)現(xiàn)定義的未命名類型不是std::function。它拷給auto可以拷給std::function也可以但你沒法在源碼里寫出那個(gè)類型的名字。標(biāo)準(zhǔn)庫這樣設(shè)計(jì)是為了保留可調(diào)用對(duì)象的直接調(diào)用能力避免無謂的類型擦除開銷。固定參數(shù)什么時(shí)候會(huì)真正派上用場(chǎng)舉個(gè)例子。你有一個(gè)日志系統(tǒng)里面的寫日志函數(shù)需要四個(gè)參數(shù)模塊名、日志級(jí)別、格式字符串、可變參數(shù)。但某個(gè)業(yè)務(wù)場(chǎng)景下模塊名和日志級(jí)別是固定的只有格式字符串每次不同。這時(shí)候bind能幫你把這個(gè)半成品函數(shù)對(duì)象到處傳調(diào)用方只需要關(guān)心格式字符串std::functionvoid(const char*, ...) logger std::bind(writeLog, network, LogLevel::Info, _1);2.2 占位符_1、_2的語義參數(shù)重排和穿透占位符是bind的靈魂。std::placeholders::_1、_2、_3一直到_N表示新生成的可調(diào)用對(duì)象在調(diào)用時(shí)接收的第1個(gè)、第2個(gè)、第3個(gè)……實(shí)參。它們可以隨意排列實(shí)現(xiàn)很多看著很神奇的效果。比如你有一個(gè)類內(nèi)部有三個(gè)參數(shù)的接口但外部回調(diào)只有一個(gè)參數(shù)struct Fetcher { int fetch(int timeout, int retries, int urlId) { // 實(shí)際邏輯 return timeout retries urlId; } }; auto task std::bind(Fetcher::fetch, fetcher, 30, 2, _1); int code task(1001); // 相當(dāng)于 fetcher.fetch(30, 2, 1001)這里_1出現(xiàn)在第三個(gè)參數(shù)位置運(yùn)行時(shí)把1001填到最后前兩個(gè)參數(shù)固定為30和2。注意綁成員函數(shù)時(shí)對(duì)象地址要作為第一個(gè)綁定參數(shù)顯式傳進(jìn)去因?yàn)槭芸爻蓡T函數(shù)在實(shí)現(xiàn)上相當(dāng)于第一個(gè)隱式參數(shù)是this。再比如重排參數(shù)。假設(shè)某個(gè)接口回調(diào)要求先傳錯(cuò)誤碼再傳錯(cuò)誤等級(jí)但你的業(yè)務(wù)函數(shù)簽名正好相反void onError(ErrorLevel level, int code); // 接口要求 void(int code, ErrorLevel level) 形式 auto adapter std::bind(onError, _2, _1); adapter(404, ErrorLevel::Warning); // 實(shí)際上調(diào)用 onError(Warning, 404)這種用lambda寫也不復(fù)雜但bind的寫法確實(shí)更短。不過可讀性嘛……我在團(tuán)隊(duì)里見過為了耍帥把參數(shù)重排排得特別亂后來維護(hù)的人看了半天不知道_2對(duì)應(yīng)哪個(gè)實(shí)參。這里我的建議是重排只適合參數(shù)少且語義清晰的情況一旦占位符超過兩個(gè)直接用lambda會(huì)好很多。2.3 引用傳遞的坑默認(rèn)拷貝還是引用這是bind里最容易踩的坑之一。std::bind綁定參數(shù)時(shí)默認(rèn)采用按值存儲(chǔ)。也就是說當(dāng)你寫std::bind(func, x)時(shí)x是被拷貝進(jìn)bind返回對(duì)象的。如果你希望函數(shù)內(nèi)部看到的是引用甚至希望修改外部變量就必須用std::ref或者std::cref顯式包裝?？磦€(gè)具體例子#include functional using namespace std::placeholders; void incr(int v) { v; } int main() { int n 0; auto f1 std::bind(incr, n); // n被拷貝f1()不會(huì)改變?cè)璶 auto f2 std::bind(incr, std::ref(n)); // n通過引用綁定 f1(); f2(); return 0; // n現(xiàn)在是1 }f1如果沒有std::ref即使incr的形參是int綁定的也是n的一個(gè)副本調(diào)用完原n紋絲不動(dòng)。這種bug特別隱蔽因?yàn)槟闳庋劭吹降恼{(diào)用關(guān)系完全一致但結(jié)果差之千里。我在某回寫線程池的提交封裝時(shí)就碰過這個(gè)。當(dāng)時(shí)想把一個(gè)外部狀態(tài)變量傳進(jìn)工作函數(shù)里累計(jì)計(jì)數(shù)忘了套std::ref跑了半天計(jì)數(shù)一直是0排查了很久才從參數(shù)按值拷貝這個(gè)點(diǎn)找到問題。后來我給自己立了個(gè)規(guī)矩bind綁定引用類型時(shí)一律明寫std::ref/std::cref絕對(duì)不靠我記得它按值存來推演。下表梳理一下綁定參數(shù)的存儲(chǔ)語義寫法存儲(chǔ)方式注意事項(xiàng)std::bind(f, x)按值拷貝xx需要可拷貝臨時(shí)對(duì)象安全std::bind(f, std::ref(x))按引用綁定x需要注意x的生命周期std::bind(f, std::cref(x))按const引用綁定x鎖住只讀防止改動(dòng)std::bind(f, ptr)按值拷貝指針指針指向?qū)ο蟮纳芷诹碚f3. 高頻實(shí)戰(zhàn)場(chǎng)景把bind用在事件回調(diào)、線程參數(shù)和算法適配里3.1 算法庫適配給標(biāo)準(zhǔn)算法換一個(gè)合適的簽名std::bind最常見的用途之一是把一個(gè)參數(shù)不對(duì)口的函數(shù)適配成算法要求的形態(tài)。舉個(gè)std::find_if的例子。假設(shè)你有一個(gè)std::vectorstd::string你想找出第一個(gè)以特定前綴prefix開頭的字符串#include algorithm #include functional #include string #include vector bool startsWith(const std::string s, const std::string p) { return s.rfind(p, 0) 0; } int main() { std::vectorstd::string v {cpp, bind, functional}; std::string prefix bi; auto it std::find_if(v.begin(), v.end(), std::bind(startsWith, _1, prefix)); return 0; }這里std::find_if要求謂詞只接受一個(gè)參數(shù)而startsWith需要兩個(gè)參數(shù)。bind把prefix固定住_1留給容器里的字符串適配就完成了。如果不寫bind你需要手動(dòng)寫一個(gè)lambdaauto it std::find_if(v.begin(), v.end(), [prefix](const std::string s) { return startsWith(s, prefix); });兩種寫法各有各的簡(jiǎn)潔。bind的版本更函數(shù)式lambda的版本更直白。從維護(hù)角度講lambda版本其實(shí)更容易看懂因?yàn)樽x者不需要記住占位符的映射關(guān)系。算法適配這個(gè)場(chǎng)景里我現(xiàn)在的習(xí)慣是如果只是固定一兩個(gè)參數(shù)bind挺好如果涉及捕獲、狀態(tài)、重排就直接lambda。3.2 線程參數(shù)傳遞從線程函數(shù)返回一個(gè)可以重復(fù)調(diào)用的任務(wù)在線程相關(guān)的代碼里bind也經(jīng)常用來把任務(wù)函數(shù)任務(wù)參數(shù)打包成一個(gè)無參的std::functionvoid()方便丟給線程啟動(dòng)。比如你有一個(gè)處理任務(wù)的類它的處理函數(shù)需要兩個(gè)參數(shù)但線程入口只接受無參函數(shù)對(duì)象class ImageProcessor { public: void process(const std::string imagePath, int quality); }; void runAsync(const std::functionvoid() job) { std::thread(job).detach(); } int main() { ImageProcessor processor; auto job std::bind(ImageProcessor::process, processor, /tmp/input.png, 85); runAsync(job); return 0; }這樣做的實(shí)質(zhì)是把類的成員函數(shù)和對(duì)象指針、具體參數(shù)一起封裝成一個(gè)可調(diào)用的任務(wù)包。線程啟動(dòng)時(shí)不需要關(guān)心ImageProcessor是什么只管調(diào)用無參函數(shù)。這種封裝方式在多線程任務(wù)隊(duì)列里特別常見。但這里我必須提醒一個(gè)很關(guān)鍵的坑如果processor是棧上對(duì)象而異步線程在processor析構(gòu)之后才運(yùn)行那就會(huì)產(chǎn)生懸垂指針訪問程序可能直接崩潰。所以bind綁定裸指針或者裸引用時(shí)生命周期必須由調(diào)用方嚴(yán)格保證。很多線上崩潰都是這句保證沒做到。更穩(wěn)妥的做法是用std::shared_ptr配合bindauto sp std::make_sharedImageProcessor(); auto job std::bind(ImageProcessor::process, sp, /tmp/input.png, 85);成員函數(shù)綁定shared_ptr時(shí)bind會(huì)保存一份shared_ptr拷貝保證任務(wù)執(zhí)行期間對(duì)象還活著。這就把生命周期問題從調(diào)用方必須記得變成了資源自己管自己。3.3 回調(diào)列表收集模擬簡(jiǎn)單的信號(hào)-槽機(jī)制在沒有引入第三方信號(hào)槽庫的情況下bind可以很輕松地構(gòu)造一個(gè)簡(jiǎn)單的回調(diào)注冊(cè)機(jī)制。假設(shè)你有一個(gè)狀態(tài)管理器當(dāng)狀態(tài)切換時(shí)希望通知多個(gè)監(jiān)聽者class DeviceStateManager { public: using Callback std::functionvoid(const std::string, int); void addListener(Callback cb) { callbacks_.push_back(std::move(cb)); } void notifyStateChange(const std::string device, int state) { for (auto cb : callbacks_) { cb(device, state); } } private: std::vectorCallback callbacks_; };注冊(cè)端可以綁定一個(gè)類的成員函數(shù)同時(shí)固定設(shè)備名class NetworkStatusViewer { public: void onStatusChanged(const std::string device, int state); }; DeviceStateManager manager; NetworkStatusViewer viewer; manager.addListener( std::bind(NetworkStatusViewer::onStatusChanged, viewer, std::placeholders::_1, std::placeholders::_2));這里兩個(gè)占位符把回調(diào)參數(shù)原樣透?jìng)鹘o成員函數(shù)。這種寫法的好處是注冊(cè)處不需要額外定義lambda也不需要把設(shè)備名手工包進(jìn)lambda。當(dāng)回調(diào)簽名較長(zhǎng)時(shí)bind的書寫可以比手寫lambda更緊湊。不過要提醒的是回調(diào)列表里存的是std::function而std::function在拷貝/構(gòu)造時(shí)可能涉及堆分配如果你的系統(tǒng)對(duì)延遲極其敏感回調(diào)特別頻繁需要評(píng)估這個(gè)開銷。我在某個(gè)高頻率事件流場(chǎng)景里就因此把std::function回調(diào)改成了直接函數(shù)指針上下文結(jié)構(gòu)體的方式。4. bind底層干了些什么從調(diào)用鏈理解為什么會(huì)有這些坑4.1 bind的返回物到底是什么樣的對(duì)象很多人把std::bind想得很玄其實(shí)就是一層包裝。標(biāo)準(zhǔn)規(guī)定了bind的返回類型是實(shí)現(xiàn)定義implementation-defined的稱之為bind表達(dá)式更好。這個(gè)表達(dá)式的內(nèi)部結(jié)構(gòu)可以大致理解為一個(gè)包含可調(diào)用對(duì)象目標(biāo)和參數(shù)元組的封裝體。當(dāng)我們寫auto f std::bind(func, 1, _2);bind內(nèi)部大致會(huì)做這樣幾件事保存func一個(gè)函數(shù)指針/成員指針/函數(shù)對(duì)象把1作為已綁定實(shí)參存入內(nèi)部的tuple中記錄_2是一個(gè)占位符而不是具體值返回一個(gè)類型未命名的函數(shù)對(duì)象它的operator()定義了當(dāng)調(diào)用發(fā)生時(shí)如何展開這些保存的參數(shù)。調(diào)用時(shí)比如寫f(a, b)bind對(duì)象內(nèi)部會(huì)按參數(shù)元組展開1直接用保存的值_2表示取調(diào)用實(shí)參里的第2個(gè)也就是b于是最終執(zhí)行func(1, b)。理解這個(gè)機(jī)制就能解釋很多現(xiàn)象bind結(jié)果對(duì)象可以被拷貝、被移動(dòng)也可以存入std::functionbind對(duì)象在調(diào)用時(shí)的參數(shù)匹配發(fā)生在其內(nèi)部展開階段因此它可以應(yīng)對(duì)多種調(diào)用簽名bind對(duì)象本身不是簡(jiǎn)單的仿函數(shù)封裝它的內(nèi)部實(shí)現(xiàn)里藏著一個(gè)tuple所以拷貝一個(gè)bind對(duì)象往往比拷貝一個(gè)lambda貴。4.2 為什么默認(rèn)按值存儲(chǔ)安全還是性能的取舍標(biāo)準(zhǔn)庫把bind的實(shí)參按值存儲(chǔ)而不是按引用在我看來是基于安全性的設(shè)計(jì)。你想bind生成的函數(shù)對(duì)象是隨時(shí)可能被傳出去、隨時(shí)可能被調(diào)用的如果默認(rèn)按引用存儲(chǔ)調(diào)用方稍不留神綁定的就是一個(gè)已經(jīng)失效的引用崩潰概率會(huì)非常高。按值存儲(chǔ)雖然有一定拷貝開銷但至少保證了對(duì)臨時(shí)值和字面量的存儲(chǔ)是絕對(duì)安全的。代價(jià)也很明顯綁定一個(gè)大對(duì)象、綁定一個(gè)不可拷貝對(duì)象、綁定一個(gè)unique_ptr都是問題。遇到這些場(chǎng)景std::ref和移動(dòng)語義就派上用場(chǎng)了。但std::ref只是看起來是引用本質(zhì)上它包裝了一個(gè)引用然后這個(gè)reference_wrapper本身被拷貝存入里面的引用依然是對(duì)原對(duì)象的引用。所以用std::ref時(shí)外部的原對(duì)象生命周期必須長(zhǎng)于bind對(duì)象這點(diǎn)約束繞不開。4.3 bind和lambda的等價(jià)替換關(guān)系搞明白bind的語義后你會(huì)發(fā)現(xiàn)bind能做的事lambda幾乎都能做反之亦然?？梢园裝ind當(dāng)作lambda的一種語法糖變體或者反過來把lambda當(dāng)作bind更自然的表達(dá)。它們的對(duì)應(yīng)關(guān)系大致這樣using namespace std::placeholders; // bind版本 auto f1 std::bind(func, 10, _1); // lambda版本 auto f2 [](int x) { return func(10, x); }; // bind版本引用捕獲 auto f3 std::bind(func, std::ref(n), _1); // lambda版本 auto f4 [n](int x) { return func(n, x); };從C11引入lambda開始bind的使用場(chǎng)景就在被壓縮。lambda的捕獲列表比std::ref直觀得多參數(shù)傳遞也更符合普通函數(shù)的直覺。尤其當(dāng)要綁定一個(gè)復(fù)雜的捕獲狀態(tài)、要修改外部變量、要移動(dòng)語義時(shí)lambda幾乎是碾壓bind的。但lambda也有不如bind的地方lambda必須寫出完整的函數(shù)體哪怕只是一行bind則只需列出哪個(gè)函數(shù)哪幾個(gè)參數(shù)。我在實(shí)際項(xiàng)目里判定的標(biāo)準(zhǔn)后面專門有一節(jié)來講。這里先給一句個(gè)人體會(huì)短小純轉(zhuǎn)發(fā)的場(chǎng)景bind讀起來更緊湊稍微帶點(diǎn)邏輯的綁定lambda更耐讀。5. 踩坑實(shí)錄綁定參數(shù)的生存期、重載歧義和移動(dòng)語義陷阱5.1 對(duì)象生命周期帶來的血案一次延時(shí)任務(wù)崩潰排查先講一個(gè)我印象最深的踩坑經(jīng)歷。某通信組件里有一個(gè)延時(shí)執(zhí)行器接收std::functionvoid()任務(wù)10秒后執(zhí)行。我當(dāng)時(shí)為了方便把一個(gè)設(shè)備配置加載對(duì)象的成員函數(shù)綁了進(jìn)去ConfigLoader loader; scheduler.scheduleAfter(std::bind(ConfigLoader::reload, loader, config.ini), 10s);問題是loader是某個(gè)局部作用域的對(duì)象函數(shù)執(zhí)行完就析構(gòu)了10秒后scheduler執(zhí)行任務(wù)時(shí)綁定的loader已經(jīng)懸垂。那一次線上表現(xiàn)為偶發(fā)崩潰壓了好久才定位到。從崩潰?？凑{(diào)用點(diǎn)完全在scheduler內(nèi)部根本看不出綁定對(duì)象已經(jīng)死了。這次的教訓(xùn)有三條我現(xiàn)在寫下來給大家參考異步延遲任務(wù)綁定裸指針/裸引用時(shí)強(qiáng)烈建議用shared_ptr包裝對(duì)象再用bind綁定如果對(duì)象屬于某模塊且生命周期可控務(wù)必在模塊析構(gòu)前把對(duì)應(yīng)的延遲任務(wù)取消不要相信這段代碼只跑一次的直覺任務(wù)一旦被排進(jìn)隊(duì)列它的生命周期就和調(diào)度器綁定而不只和當(dāng)前作用域綁定。修復(fù)后的寫法auto loader std::make_sharedConfigLoader(); scheduler.scheduleAfter( std::bind(ConfigLoader::reload, loader, config.ini), 10s);這樣任務(wù)會(huì)持有一份loader的引用計(jì)數(shù)直到任務(wù)執(zhí)行完。用這種寫法后同樣的崩潰再?zèng)]出現(xiàn)過。5.2 重載函數(shù)綁定的歧義編譯器讓你寫得更啰嗦如果你試圖直接bind一個(gè)重載函數(shù)大概率會(huì)得到編譯器的一頓抱怨因?yàn)閎ind需要從調(diào)用簽名推導(dǎo)要綁定哪一個(gè)函數(shù)。這個(gè)問題第一次碰到時(shí)我還沒反應(yīng)過來覺得這么簡(jiǎn)單的事為啥編譯不過。void handle(int) {} void handle(const std::string) {} auto f std::bind(handle, _1); // 編譯錯(cuò)誤handle不明確解決辦法是先把重載解析確定下來也就是顯示地把函數(shù)指針轉(zhuǎn)型using IntHandler void(*)(int); IntHandler h handle; auto f std::bind(h, _1);寫成這樣就明確告訴編譯器綁定的是void handle(int)。函數(shù)指針轉(zhuǎn)型這行代碼雖然丑但同時(shí)也讓閱讀代碼的人清楚你綁定的是哪個(gè)重載。相比之下lambda版本就不會(huì)遇到這個(gè)問題因?yàn)閘ambda內(nèi)部的調(diào)用發(fā)生在模板展開時(shí)編譯器可以上下文推斷出重載。5.3 移動(dòng)語義的斷層為什么bind綁定不了unique_ptr這是bind和現(xiàn)代C最格格不入的一個(gè)點(diǎn)。std::bind在綁定參數(shù)時(shí)默認(rèn)按值存儲(chǔ)而按值存儲(chǔ)對(duì)std::unique_ptr這種不可拷貝的對(duì)象編譯直接失敗。更麻煩的是就算你綁定一個(gè)右值類型的對(duì)象bind內(nèi)部也是把它拷貝而不是移動(dòng)auto p std::make_uniqueint(5); auto f std::bind(process, p); // 編譯錯(cuò)誤unique_ptr不可拷貝 auto f2 std::bind(process, std::make_uniqueint(5)); // 同樣不行可以配合std::ref但前提是p活得夠久。實(shí)際上要用unique_ptr做異步轉(zhuǎn)發(fā)的場(chǎng)景l(fā)ambda是更好的選擇auto f [p std::move(p)]() mutable { process(std::move(p)); };移動(dòng)語義的斷層是bind出生年代決定的C11設(shè)計(jì)bind時(shí)對(duì)移動(dòng)的支持本身就有限后續(xù)標(biāo)準(zhǔn)也沒有專門修補(bǔ)。所以我的結(jié)論是只要涉及移動(dòng)語義直接拋棄bind別在它身上浪費(fèi)時(shí)間。5.4 bind對(duì)象拷貝開銷與std::function類型擦除每當(dāng)你把bind結(jié)果存進(jìn)std::function綁定參數(shù)會(huì)被再一次復(fù)制/移動(dòng)封裝。如果綁定的是一個(gè)大圖片對(duì)象、大字符串或者復(fù)雜結(jié)構(gòu)體一次bind存function的過程可能發(fā)生多次拷貝。一個(gè)典型的反例struct BigData { char buffer[1024 * 1024]; }; void process(const BigData); BigData data; auto cb std::functionvoid()(std::bind(process, data)); // data被拷貝多次這種代碼不僅會(huì)產(chǎn)生大塊內(nèi)存拷貝還有可能帶來緩存不友好。處理方法是綁定的時(shí)候用std::cref(data)讓bind內(nèi)部只存引用包裝避免大對(duì)象拷貝。但前提依然是data的生命周期必須覆蓋到cb被調(diào)用的時(shí)刻。提示大對(duì)象綁定的性能問題可以通過綁定shared_ptr或者std::cref規(guī)避務(wù)必根據(jù)對(duì)象生命周期做選擇。6. bind和lambda怎么選一份基于實(shí)戰(zhàn)的取舍清單6.1 什么時(shí)候bind依然是更好的選擇我手頭項(xiàng)目里現(xiàn)在還在用bind的地方歸納起來只有四類第一綁定成員函數(shù)且參數(shù)基本固定。寫std::bind(Class::method, obj, _1)比寫[obj](int x){ obj-method(x); }短不少而且意圖清楚。第二函數(shù)式組合風(fēng)格。例如在配合其他泛型組件時(shí)bind表達(dá)式可以直接作為std::function傳入lambda的寫法往往要多包一層花括號(hào)和返回類型推導(dǎo)。第三作為標(biāo)準(zhǔn)算法適配器。在std::find_if、std::transform這類需要固定參數(shù)時(shí)bind版本比較緊湊。第四參數(shù)重排。雖然可讀性有代價(jià)但參數(shù)多且重排邏輯簡(jiǎn)單時(shí)bind確實(shí)比lambda更快寫完。6.2 什么時(shí)候直接寫lambda別猶豫反過來下面這些場(chǎng)景我?guī)缀趿悛q豫直接寫lambda綁定參數(shù)要修改外部變量需要引用捕獲或按移動(dòng)捕獲目標(biāo)函數(shù)是重載函數(shù)、模板函數(shù)需要編譯器做類型推導(dǎo)綁定對(duì)象是unique_ptr或移動(dòng)語義的傳遞lambda內(nèi)部有不止一行邏輯或者需要分支、循環(huán)代碼正在被別人長(zhǎng)期維護(hù)可讀性是第一優(yōu)先級(jí)。我自己還有一個(gè)非常主觀的標(biāo)準(zhǔn)當(dāng)bind表達(dá)式中占位符出現(xiàn)的順序需要仔細(xì)數(shù)的時(shí)候直接lambda。bind的簡(jiǎn)潔性在占位符一多時(shí)會(huì)迅速崩塌。6.3 我給團(tuán)隊(duì)的建議如果讓我給一個(gè)團(tuán)隊(duì)寫一條規(guī)范大概是這樣的固定this指針、固定一個(gè)參數(shù)、參數(shù)就一兩個(gè)時(shí)允許用std::bind其余情況一律用lambda任何情況下禁止為了參數(shù)重排寫超過2個(gè)占位符的bind表達(dá)式涉及引用綁定必須顯式寫std::ref/std::cref不允許默認(rèn)按值推斷禁止把裸指針、裸引用綁定到延遲執(zhí)行的任務(wù)里必須用shared_ptr。這些規(guī)則談不上絕對(duì)正確但確實(shí)是從一堆線上問題里長(zhǎng)出來的。最后再分享一個(gè)實(shí)用習(xí)慣我現(xiàn)在寫代碼時(shí)會(huì)順手做一件小事bind表達(dá)式只要超過一行或者出現(xiàn)兩個(gè)以上占位符我就立刻改寫為lambda。不是因?yàn)閎ind不能用而是因?yàn)榘肽旰螽?dāng)你回頭改BUG時(shí)快速讀懂代碼比少敲幾行字重要得多。C里有很多工具都在短期內(nèi)幫你偷懶和長(zhǎng)期內(nèi)增加認(rèn)知負(fù)載之間搖擺bind正是其中之一。另外如果你用的C版本允許C20新增的std::bind_front可以覆蓋一部分簡(jiǎn)單的前綴參數(shù)綁定場(chǎng)景它在語義上比bind更收斂也不涉及占位符重排只要固定參數(shù)在最前面它就是比bind更明確的選擇。講了這么多其實(shí)核心就一句話bind是個(gè)好工具但它有自己的適用邊界。搞清楚它背后是怎么存的、怎么展開的、生命周期要求是什么你就能在該用它的時(shí)候放心用在不該用它的時(shí)候果斷換掉。這個(gè)邊界只有親自踩過坑的人才真正畫得清。