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