Boost裡已經有的輪子一定要自己造是一種怎樣的心態？

1樓：大雄

「工匠精神」

啥是工匠精神？就是研究細節，極限優化，別人做的成熟，我做的輕量；別人做的通用，我做的極限優化；別人做的簡單，我做的通用；別人做的輕量，我做框架。

嗯，反正我就是厲害！

2樓：

就是那種，要實現某某輪子，別的公司已經有了妥妥的，堅決不用，自己開發乙個/收購乙個，做到「自主的，不依賴其他公司」。

這是一種怎樣的心態？屬於一種蹭得累麼？還是說確實存在很多公司/生產環境被其他公司限制過？

3樓：SmartLife366

我有時也會造輪子，通常是因為：

1，自己水平有限無法完全駕馭boost庫。萬一出個錯，或有個bug就束手無策了。就錯誤提示就夠嚇人的。

boost原始碼看又看不懂，改又不敢改。自己寫的庫，自己能駕馭，出了錯自己能改。

2，嫌boost庫太臃腫，不簡潔。通常我只會使用一兩個介面，一兩個類，結果它把所有的囊括了，有幾十個介面，容易用錯。而且體積大，特別是在嵌入式裝置上，那相應臃腫。

自己寫的會有一定的目的性，會更適應於當前應用場景。

3，自己練練手，提公升能力。

4樓：

拋開工作不談，自己用c++造輪子是一種想要變強的心態。

比如寫consensus protocol，比如和標準實現比效能和擴充套件性。

5樓：stlf

Boost過於追求適應各種情況的完美實現，或者說Boost本身是帶有實驗性和前瞻性，有點忽視了工程實用性。groups.google.com/d/msg

/pongba/B1Afb_Obf_A/hnMGOpgxMtAJ

在boost 中大量使用了模板這一"靜態型別生成器"，乙個模板的引數化，在編譯器看來好似是有乙個類被宣告了， boost中的模板在編譯期間生成

了大量對於庫使用者不知道的類，即"中間類"（不知道這樣描述是否合適?），而這些"中間類" 和靜態設施一起在編譯期使編譯器幫我們計算（很多是利用

模板的靜態遞迴特性）了很多靜態內容。其實這些都是複雜因素，這些都對編譯器提出了要求：靜態計算也是要耗時的，耗的是編譯時間，長時間的編譯對開發者不是好的體驗。

工程中引入Boost庫的最大問題是依賴和編譯時間成本，這兩點直接影響開發體驗。

有時候模仿Boost造一些精簡並減少依賴的輪子，對實際專案開發還是有益的。

6樓：「已登出」

雖然我覺得我寫的不一定好，但坑一定少（因為需要的不多），改的又方便，看著也比boost舒服（沒了boost汙染命名空間）。

7樓：VeroFess

哥們你想想乙個後門木馬遠控帶上個5M的庫傳過去是個啥鬼

別逗了哥們…

我寫win下的連msvcrt都不要，就為了讓程式小一點

8樓：新生命

其他答主回答了庫的大小這些方面。我說乙個方面。

boost很多庫都使用了奇技淫巧。有的甚至利用了編譯器的bug去實現一些功能。引入boost會讓整個專案不可控，增大除錯難度。讓專案unstable。

9樓：李登淳

哎呀，學生時代嘛，自己不實現怎麼知道原理呢？

另外也有歷史原因，比如我的一些程式，寫的時候C++17還沒出來，另外也是想相容舊一點的編譯器，於是比如說Any這種東西就自己實現了。為啥不用Boost？還有乙個原因就是在非Linux平台上配置死麻煩。

10樓：nyycbd

在閱讀能力有限的情況下，自己造的輪子脾性更清楚，也不容易用錯，甚至可以隨便改動、精簡原始碼。假設boost某庫有個功能不合要求，你想稍微改一下，結果點開乙個一萬行的原始檔各種boost::detail::

__wtf_helper::__wtf_helper_impl::foo(bar,baz) const noexcept，你敢隨便動嗎？

萬一異常處理，右值語義，特化模板，CRTP，隱式轉換，過載決議踩坑了呢？

11樓：

很多時候這是為了讓自己的庫更為輕量。而且有些輪子從出生開始就是為了成為萬用輪而製造的，自然也伴隨著一些妥協。當你只想用到其中的一部分時候，找/造乙個單一用途的輪子並不是一件奇怪的事情。