一直以來，我在教授C++語言編程課程的時候，總是在泛型上慌得很，生怕自己的半吊子C++知識貽笑大方。還好我發現同學們和我一樣都是糊涂蟲，只滿足于把STL的容器和算法當作簡單類型用就完了。印象深刻的一次尷尬就是學生問我：丁老師，怎么你給的例子的鏈表，和std::list的鏈表差別這么大，學了泛型，怎么還是看不懂STL庫的代碼呢？

我只能說，師傅領進門，修行靠個人，我也不懂哩！其實老師眼都看花了，也是看不懂。最近終于看完了，更覺得頭大。通過20年的教學，悲哀的發現一個事實，** 哪怕學完一本教材，讓我實現一個鏈表或者字典，也絕對不會長得像STL庫 **。每次試著研究STL庫、BOOST庫的源碼，總是覺得在鞭撻我的靈魂，PUA我，讓我知道我只是一個C語言學了一半的三流本科野路子。這種情況讓我痛不欲生，直到看到了Qt的源碼，才重新心情好起來：原來Qt的源碼風格非常適合我的口味，每次一打開，我受傷的靈魂就得到了安慰。

Qt實現可讀性好

對于這種泛型庫，都是沒有CPP的，也就是在頭文件里直接引入所有代碼。可以認為是內聯的。但哪怕只有.h文件，可讀性也有不同。

文本排版

雖然對頭文件來說，ALLinOne可以不管排版，但一般來說，我們實現一個類，還是喜歡不把實現直接寫在類的聲明里。這樣會顯著分散接口的文本描述，讓維護者不知道這個類有多少方法。STL庫大部分方法是直接寫在A的聲明里：

class A{ //...FunA(){//50行}FunB(){//50行}//... }

Qt把比較冗長的方法的聲明、實現分開陳述。

class A{ //...FunA();FunB();//... } A::FunA(); {//50行 } A::FunB() {//50行 }

Qt這樣做的好處是，這個類的全貌盡收眼底。就像是你寫論文的時候，有個目錄，而不是上來就第一段。STL庫這樣寫，2000多行的程序，上來就把人打蒙了。

此外，Qt的縮進、大括號的配對都比較美觀。相對起來g++的STL就隨意多了。

命名風格

二者的命名風格大不相同。就拿 list::push_front來看
STL:

voidpush_front(const value_type& __x){ this->_M_insert(begin(), __x); }// Inserts new element at position given and with value given. #if __cplusplus < 201103Lvoid_M_insert(iterator __position, const value_type& __x){_Node* __tmp = _M_create_node(__x);__tmp->_M_hook(__position._M_node);this->_M_inc_size(1);} #elsetemplate<typename... _Args>void_M_insert(iterator __position, _Args&&... __args){_Node* __tmp = _M_create_node(std::forward<_Args>(__args)...);__tmp->_M_hook(__position._M_node);this->_M_inc_size(1);} #endif#endif

Qt:

inline void push_front(const T &t) { prepend(t); } template <typename T> inline void QList<T>::prepend(const T &t) {if (d->ref.isShared()) {Node *n = detach_helper_grow(0, 1);QT_TRY {node_construct(n, t);} QT_CATCH(...) {++d->begin;QT_RETHROW;}} else {if (QTypeInfo<T>::isLarge || QTypeInfo<T>::isStatic) {Node *n = reinterpret_cast<Node *>(p.prepend());QT_TRY {node_construct(n, t);} QT_CATCH(...) {++d->begin;QT_RETHROW;}} else {Node *n, copy;node_construct(&copy, t); // t might be a reference to an object in the arrayQT_TRY {n = reinterpret_cast<Node *>(p.prepend());;} QT_CATCH(...) {node_destruct(&copy);QT_RETHROW;}*n = copy;}} }

STL庫的變量名，太多的下劃線（__）和奇怪的前綴，比如_M_, 可讀性太差。namespace是可以嵌套的，既然這么怕重名，還不如定義namespace呢。

其實Qt吸引我的遠不止上述這些，我在開發工具上的個人口味，決定了我在用Windows開發時，只愛 MSYS2, 以及里面的Qt。

個人口味

我一直覺得自己水平很差，還敢教學生寫代碼。唉，真的慚愧。不過我發現可能我這樣水平的人，真的不適合學習純粹的C++、不適合學Java，不適合學Python，不適合學C#，還是學習Qt吧。沒辦法，寫了這么多年程序，從Logo語言（中華學習機）、GWBasic, Qbasic, VisualBasic, TC2.0, TC3.1, Borland C++/BCB，VC/MFC 到 GNU C++, Java， Python，node.js, plpgSql, plsql ， Excel 以及VBScript, bash,……需要啥子，就學啥子，但是不代表我都喜歡——有些東西，我一直難以習慣，即使看得懂，也很難喜歡——不合口味。

討厭的口味

下劃線、非字母開始的變量 :如Bash的 $()，以及STL實現里的__xxx

全大寫的東西 : 老式Basic語言, 很多公司建立的SQLServer， Oracle模型。

超過兩層或者10個字符的引用: Java的一堆包.Axxx.Byyyyy…，C#的System.Math.XXXXX,以及 boost/ C++20 的 std::chrono::system_clock::now

把實現直接寫在Class里： Java、C#, STL都這樣干。

弱類型語言: 在競賽時，曾經因為把 backaside 變量在某處誤寫為 backside，結果程序不報錯，痛失冠軍。從此拋棄任何不需要顯式定義變量的語言。

發布時需要另外攜帶解釋器、虛擬機、子安裝包：Python, Java(jvm)，C#(clr), Basic, Node.js, Matlab，vcredist等等。

發布、運行時要使用注冊表、環境變量：注冊表一堆東西，而后在環境變量配置一堆東西。

運行時文件夾文件太多，又小又碎:把程序發布給終端用戶，還要攜帶大量html，png,資源，攜帶大量腳本。一個文件夾里上萬個文件（人家是要使用，不是開發）。

深埋文件夾：把自己安裝在user/UserName/appData/…下，并在Local里有好多垃圾文件。

C++庫、COM/OLE、.Net:一定是C的庫，C的庫是最簡單，兼容性最高的。哪怕用C++，用Qt，都要導出C接口的庫，而不是C++的。

文本接口: JSON和XML可讀性好，但是解釋這些東西很浪費時間。寧可解決大小端、二進制兼容性問題，也不想為了解釋文本引入第三方庫。

非原生IDE：IDE應該一開始就是為了核心工具鏈研發的，而不是萬精油的。哪怕我喜歡Qt，也盡量避免在VS里使用Qt。

喜歡MSys2Qt的原因

開發環境無污染:msys2是文件夾封閉的，在線安裝后，重裝系統了，直接釋放原來的備份壓縮包，一切如初。

發布環境無污染:msys2 Qt的依賴是封閉的，發布時，直接放在文件夾里，拷貝齊了動態庫，就不用要求用戶安裝任何東西。對比起來，msvc Qt可能需要安裝VC運行時。重要的是文件夾里放的東西不是很碎。

開源、跨平臺:存粹喜歡開源。現在犯了強迫癥，自己寫的代碼總是要在x86,x64,arm,arm64上編譯，都能用了才開心。用MSYS2 Qt,基本很省心。

庫較為完整:在windows下，基本上常見的Linux C庫都有實現，且不用配置。MSYS2就是一個完整的小bash環境。

效率高:與Cygwin相比，用的是Mingw，沒有API轉接，效率很高。

API優雅 Qt的API非常優雅，一致性很高。

文檔優雅 我覺得，看過的文檔里，MSDN、Archlinux、Qt、PostgreSQL這四個東西的文檔給我的印象很好，除了MSDN，其他三個和MSYS2都有交集。

源碼優雅 源碼我看得懂！不PUA我，不鄙視我。

總觀點

MSYS2 + Qt是給一個一般水平的科研工作者開發出工業級別生產力工具的極佳解決方案。不需要很多的投入，就可以開發出跨平臺的、綠色版的高度可用的生產力工具。

總結

以上是生活随笔為你收集整理的程序猿的口味-从C++STL聊到MSYS2-Qt的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。