如何評價基於 C++ 17 的框架 MCF？

01-15

MCF 遵循「無塵設計」的原則。
其設計目標是將 C 和 C++ 的標準庫連帶 CRT 全部丟棄，然後重新設計，以期移除任何雜質和智障功能，包括區域和語言設置、標準輸入輸出流、線程和 thread_local 等。

GitHub - lhmouse/MCF: Meta-purpose C++ Foundation

我覺得這是相當牛逼的一個炫技作品，不僅體現了作者強大的編碼能力，還滲入了作者自己對語言標準、運行時標準庫這一套基礎設施的理解

我覺得作者想表達的實際上是：不管你們用不用，反正我能寫

我覺得很叼

還是不夠徹底，竟然還有std字樣出現（逃

這幾個名字看起來好眼熟，一時想不起來是誰了……

那個FrankHB好像是帝球？那個lhmouse是誰來著？

那libstdc++呢?沒吃飯給人一種有氣無力的感覺

最晚大二就在寫了吧，沒想到現在還在寫。念念不忘，必有迴響。

PS：此哥單身，二十五左右，願萬能的知乎賜其良緣。

PPS：魔都之外的各路HR挖人也請趁早，此哥一旦找到對象恐怕就不會挪窩了…

PPPS：在下也單身^_^

YSLib可否一戰？

一個女孩子家取個什麼名字不好，非要叫潘蓮金。。。

沒細看，感覺像語言理念強迫症，要弄出一套完美的體系

不如再做深一點，把C++那些因為歷史或其它原因的難學的語法都做改造了，是不是價值更大

有能力

不實用

代碼我看過，抄過，編譯過，運行過。

首先File介面兩個參數調換了順序（這是很老的事情了），但他們的類型是一致的，於是我的引擎：、、、

當然這更體現了該作者不做任何兼容性設計，這對於實際項目很致命。。。

還有你不能用普通的mys2工具鏈去編譯他，否則編譯出來的東西炸媽。

需要配套使用mcfthread模型，該版本的gcc在lhmous網站上有下載

還有為了抄那些彙編數學函數，抄的我很蛋疼。我用的是cl，MCFCRT沒用這些的時候他教我寫的....

至於與YSLIB的優越性：

第一,YSLIB更加容易遷移到CL，儘管編譯出來效率炸媽

如果yslib用某thread而MCF用mcfthread，我只能說,MCF完爆不解釋

以為MFC大更新

從頭擼輪子，很有魄力。自得其樂，挺好的。

第一眼看成MFC了。看到代碼裡面的數學庫sin,sqrt等實現後，造輪子的能力已經突破我的認知了。可惜好像不能跨平台。總感覺作者的聰明才智用的不是地方。

這個輪子比那個輪子要更輪子。

可以這很輪子

第一次聽說這樣的框架

說實話C/C++很多歷史遺留問題，以及設計者根本考慮不周全一廂情願瞎JB搞出的問題太多了，這種東西的出現可以說是完全符合歷史的行程，只不過就是那個奮鬥的個人是誰，什麼時候出現的問題了。

簡單說，你看看稍大型的項目里有多少Util，就知道現在C/C++社區缺多少東西/有多少東西設計的一灘屎。不是大家不想用std，能好好寫代碼（真的實現C++他爹吹噓的no runtime overhead）誰TM願意費那心思用別的東西。

另外有些東西雖然屎，但是幾乎不可能成為性能瓶頸的，其實幾代人也就這麼吃下去了。（比如fopen的參數 "r" "w"，現在通識是使用bit mask。）這部分東西除了qt這種框架級別的項目要另起爐灶，剩下的一般項目除了已經使用某種框架的，基本也沒啥必要換。

代碼質量無法現在評估，但移植性和兼容性的問題看了眼其他回答，不是很樂觀。

我曾經為了解決msvc上crt一些XX實現的問題也修改過微軟的header，包括crt和c++的，後來並沒有做成一個十分全面的修改，因為我的理想當然是保持兼容性的前提下做這一切。

雖然輪子哥 @vzch 在知乎很多回答很划水，但他寫的GayUI確實是考慮到了移植性和兼容性的問題，你可以說MCF的作者是能為之而不為之，但是就我的經歷來說，保持兼容性、移植性真的完全是臟活累活。

且不說他設計的API是否真的比C/C++已有的優越，兼容性做的不好恐怕就足以令很多人望而卻步了。更何況從他對stream的設計來看（因為我好奇他file相關的東西要怎麼設計就去翻了翻目錄結構），我覺得他的stream類是面向functionality的utility的stream，而非面向zero-overhead，syscall (winapi) affinity。

再去翻他的模板類，也沒有address template bloat的問題，而且從設計上我贊成try-catch的，但從現階段C++編譯器不能把try-catch中的靜態路徑優化掉的尿性，你這樣寫了代碼你還怎麼讓人用（比起C++ std一些常見實現沒有優勢不是嗎）。

而且他的allocator的理解也有問題。他永遠都調用新的allocator來分配內存（即Allocator()(size)）。而allocator在C++ std中的設計是每個instance有個單獨的allocator的instance。他的那個allocator class相當於無法擴展（擴展功能只能依賴於static/global var），而C++ std的allocator雖然也有設計的不好的地方（關鍵在於各種類型間cast的部分，這部分我也不指望他能有更好的設計），但是擴展起來的可能性比他的要高。

（如果你們自己看C++ std的容器，你會發現其實構造函數里有個隱藏的參數是const Allocator，擴展功能就是從這兒來）

@孫明琦的回答

我覺得這是相當牛逼的一個炫技作品，不僅體現了作者強大的編碼能力，還滲入了作者自己對語言標準、運行時標準庫這一套基礎設施的理解

github上各種C++的stdlib的練手也好不練手也好的實現很多，數個兩位數不多吧。我看過的裡面相當一部分其實也都是對於stdlib做了擴展或者其中一部分功能略有改變。

如果要我評價他炫出來的技，

C和架構可以給80分。但要注意這部分技本身內容很少。一個正常CS本科學好架構學好彙編，花半年時間搞到這個程度都嫌時間長。這部分進階的東西請去ffmpeg，或者參考Agner Fog

C++和語言設計，顯然就我上面點出來的這些問題點，這位同學是得不了高分的。這部分技的內容要比上面的要多得多，我自認為我自己是沒有那個能力給這部分內容打分的。