C++開源庫詳細介紹

C++在“商業應用”方面，曾經是天下第一的開發語言，但這一桂冠已經被java搶走多年。因為當今商業應用程式類型，已經從桌面應用迅速轉移成Web應 用。當Java橫行天下之後，MS又突然發力，搞出C#語言，有大片的曾經的C++程式員，以為C++要就此沉淪，未料，這三年來，C++的生命力突然被 嚴重地增強了。主力原因就是開源的軟體、基礎軟體（比如并發原生支援，比如Android必定要推出原生的SDK）、各種跨平台應用的出現。

開源C++庫必須具有以下特點：必須是成熟的産品、跨平台的産品、相對通用的庫。

一、通用标準類

STL：C++标準模闆庫，呵呵，它也是開源的嘛。

boost：C++準标準庫，它是強大地，江湖稱之“千錘百煉”。

——-若掌握，必橫行世界。

deelx （輕量級的正規表達式解析類庫，國産），boost裡有強大的正規表達式解析庫，但如果你隻想要一個表達式解析，不想要拖上龐大的boost庫時……支援一下國貨。

iconv /iconvpp ： (C形式的編碼轉換函數庫，

二、XML解析庫

C++的XML相關庫不少，但是大部分其實都是C庫，使用起來自然不那麼輕便。其中基于DOM的有TinyXml，基于SAX的當然是Xerces。前者小巧快捷，便于使用，适合做資料交換。後者則是全功能的XML解析器。

哥更傾向于TingyXml.小巧啊！

xerces-c ：最強大的XML解析庫了，不是僅僅在開源庫裡，你盡管把商業的算在内。當然，它的變體，被IBM拿去賣錢的那個版本，多了數百兆的東東來支援各國編碼轉換，是更強大，但我覺得有小小的，開源的iconv在前不就夠了？

根據博友的一篇博文http://www.cnblogs.com/wuqi924/archive/2010/11/18/1880950.html

對三個輕型xml解析開源庫：SlimXml、TinyXml、RapidXml，對比如下：

解析這個3.3萬行，1.5M大小的xml，三個庫分别花了

•SlimXml: 22ms

•TinyXml: 54ms

•RapidXml: 4ms!

結論是，RapidXml果然很強悍，居然比SlimXml快5倍多。

比較欣慰的是，在沒有很關注效率的情況下，SlimXml仍然比TinyXml快2.5倍。SlimXml走的是簡單小巧路線，源代碼隻有 32k，而TinyXml和RapidXml的源碼分别是147k和141k，有這樣的效率可以滿意了。因為這個庫主要還是針對幾十上百行的小檔案，解析特别大的xml不在我考慮的範圍之内。

還有irrlicht（鬼火引擎）的irrXMl解析器。

xsd (XML 與 C++資料結構的綁定工具)。（商業使用要錢）

三、資料庫

我比較喜歡OTL（用于連接配接資料庫）。其他的沒用過

四、多媒體類

—摘錄别處，自己，沒用過

SDL (Simple DirectMedia Layer/多媒體直接通路層，用于遊戲程式設計)。

相應的c開源庫有ffmpeg、mpeg4、aac、avc、libmad、mpeg1、flac、ac3、ac3、matroska著名的多媒體播放器 TCPMP 天下聞名的跨平台、嵌入式手持裝置視訊播放器，

五、網絡開發類

1、gSOAP SOAP協定的C++支援庫及代碼生成工具。

2、ACE 網絡程式設計研究首選。

ACE适合于研究，大型網絡程式設計上效率不足，大型網遊裡面幾乎沒有用到ACE的，很多用了ACE的項目也被證明了效率不高。

除了ACE之外，還有很多系統和網絡程式設計方面的程式庫。比如線上程庫方面，還有ZThread、boost::thread，如果放大到C/C++領域， 還有APR，還有CII。在檔案和目錄操作方面，boost也有相應的元件，而在網絡程式設計方面有socket++，還有boost::asio，未來的 C++0X中幾乎肯定有一個網絡程式設計和一個線程庫。然而目前看來，ACE仍然是進行系統和高性能網絡程式設計的首選，其地位在一段時間内不會被撼動。它不但是 一個實用的程式庫、架構集，還是一個典範的設計模式應用範例，非常值得學習。

3、有博友回複到POCO。我整理如下：

開源C++庫，稱為POCO（POrtable COmponents – 可移植元件），非常友善好用。

特性：

* 線程，程式同步及多線程程式設計進階抽象

* 流及檔案系統通路

* 共享庫将類加載

* 功能強大的日志和錯誤報告

* 安全及加密

* 網絡程式設計 (TCP/IP 套接字, HTTP用戶端和HTTP伺服器, FTP, SMTP, POP3, 等)

* XML解析 (SAX2 和 DOM) 及生成

* 配置檔案及選項處理

* SQL資料庫通路(ODBC, MySQL, SQLite)

可以運作的平台包括：

* Windows

* Mac OS X

* iPhone OS

* (embedded) Linux

* HP-UX

* Tru64

* Solaris

* QNX

六、GUI庫

BCG Windows平台下界面設計的第三方庫，可以讓你的界面更美好，更具時 代感。

wxWidgets ：使用wxWidgets ，開發者可以基于同一套代碼，為Win32, Mac OS X, GTK+, X11, Motif, WinCE等平台開發應用程式。wxWidgets庫可以被C++, Python, Perl, and C#/.NET等開發語言使用。跟其它有些同樣支援跨平台GUI開發工具不同，基于wxWidgets的應用，擁有真實本地化的視覺及使用效果——因 為，wxWidgets使用（各）平台原生的控件，而不是簡單通過貼圖去模拟。wxWidgets是使用廣泛的，自由的，開源的，成熟的。

QT————-界面（GUI）開發，支援C++/Java/Python/…多種語言。跨平台。最主要的好處是，API非常優 美！Qt本身也不僅僅隻是做GUI程式設計，實際它基本上可以做OS-API可以做的任何事情。象網絡/資料庫/OpenGL/…都提供完美的支援。

傳統上Qt被認為是可移植的GUI庫，但實際上Qt現在已經是一個比較完整的可移植應用程式架構了，其中包含了大量的工具，比如正規表達式、Web和 Socket類、2D和3D圖形、XML解析、SQL類等，甚至還包括了一個完整的容器類庫，不過其王牌還是GUI。在目前的跨平台GUI架構中，Qt成熟度最高，已經被一些大公司應用在關鍵産品中。由于Trolltech對Qt采用的dual license模式，該産品既可以從開源社群獲得支援，又能夠賺取足夠的商業利潤，是以其前景也令人比較有信心。

Qt的主要技術特色是其元對象模型。Qt實際上使用的并不是标準的C++，而是标準C++的一個擴充。它通過元對象模型擴充，實作了著名的signal/slot機制，而這一機制也成為Qt的最大特色和優勢。

與Qt類似的可移植GUI架構還有wxWidget、FOX等

六. 計算機視覺

　　OpenCV，因特爾自主的開源庫。支援C/C++/Python接口。這個感興趣的朋友可以玩一下。如果結合OpenCV，你可以做一些外行人覺得很酷的程式。比如說用它的人臉識别函數，來對你的攝像頭進行處理，判斷人的動作等

七. 圖形圖像處理

GDAL，處理大圖像。　要是GIS專業的人肯定會語言到非常大的tif影像，動則幾個GB的航空影像。GDAL對大圖像的讀寫支援是非常棒的（像多波段的圖像都可以搞定）。　　支援C++/Java/Python…

國外開源的GIS軟體QGIS就是用了gdal

c的圖形圖像庫較多，libjpeg、libpng、zlib、tiff、JBIG、最著名的開源形圖像處理軟體Cximage

八、記憶體管理：boost::smart_ptr，Hans-Boehm GC

C/C++的記憶體管理是一個永恒的話題。一般來說，C++的開發者傾向于自己管理記憶體。然而，出乎很多C++開發者意料的是，近期C++的一些領袖人物已經公開宣稱，如果不配備自動記憶體管理機制，用C++編寫安全可靠的大型程式是非常困難的。而Bjarne Stroustrup也曾對中國開發者建議，如果沒有特别的理由，應該在大型項目中使用自動記憶體管理工具。是以，今天的C++開發者應當積極地學習和應用自動記憶體管理設施。

說到自動記憶體管理，比較輕量級的做法是boost::smart_ptr，而激進的做法是引入完整的GC機制。目前開源而又比較可靠的GC中，Hans- Boehm GC無疑是最受信賴的。作為一個保守的GC，Hans-Boehm GC在性能和功能方面都算是卓越。特别是，使用這個GC，你仍然可以delete、free來自己管理記憶體，對于我們程式設計習慣的沖擊比較小。

九、密碼及安全：OpenSSL

安全是今天進行C/C++程式設計無法回避和必須重視的問題。然而編寫安全的應用程式，特别是跟網絡相關的C/C++應用程式，是一件十分困難的事情。可以 說，整個業界目前在這個程序上仍然處于“初級階段”。特别是涉及到大量的安全、密碼學相關的算法、規範，如果讓開發者自己摸索，其工作量和難度達到了不現 實的程度。是以必須借助可靠的相關程式庫才有可能提高程式的安全性。在這方面，OpenSSL是目前最好的選擇，其内容之全面可靠，已經成為業界标杆。然 而，由于安全程式設計固有的複雜性，即使使用penSSL，開發工作仍然是非常繁瑣的。是以我們也希望能夠盡快看到更簡單、更易用的C/C++安全程式庫。

十、矩陣計算：MTL

自1995年以來，C++在科學計算領域當中取得了巨大的突破。這主要歸功于template技術的進階應用，使得C++在科學計算的性能方面取得了巨大 的進步，一大批優秀的C++科學計算庫湧現出來。比如Blitz++、POOMA、MTL、Boost::uBLAS。而這其中，MTL就功能豐富程度、 性能、開發支援和成熟程度來講，是比較突出的一個，是以可以優先考慮。值得一提的是，2002年，MTL與後來被Intel收購的KAI C++配合，曾經在性能評測中擊敗了FORTRAN。

十一、中間件

1、分布式對象中間件：ICE

ICE是分布式對象中間件領域裡的後起之秀，可以大緻地将其視為“改進版”的CORBA。目前應用在一些大型項目當中，其中包括波音公司主持的下一代陸軍作戰系統。

ICE的一個特别價值是其代碼的範例意義。由于ICE的出現較晚，開發者比較系統地應用了新的C++程式設計風格，是以成為了研讀C++代碼的良好目标。

2、消息中間件：ZeroMQ，總結的幾種特性如下：

1） 消息系統中，它差不多是最簡潔的，隻是個簡潔的API，有n多種語言的綁定，沒有專門的伺服器；

2） 性能非常優越，遠遠高于RabbitMQ、ActiveMQ、MSMQ等；

3） 适合做分布式和并發應用。

十二、正規表達式：boost::regex

正規表達式是程式設計工作中最強有力的工具之一。C++的正規表達式支援一直以來是一個軟肋。大約在2001年左右，boost中出現了regex庫，初步解 決了這個問題。但是最初的regex無論在效率上還是可靠性方面都有一些問題，後來經過一次大規模的翻修之後，達到了比較完善的程度。

其他可以選擇的替代品還有C語言的pcre庫，Qt中的QRegExp類等。

十三、配置管理：Lua

随着軟體系統越來越複雜，對軟體的可配置型提出了越來越高的要求。傳統上隻要通過指令行參數來配置的系統，現在可能需要越來越多的方式和機制。目前越來越 受歡迎、并且得到越來越多證明的做法，是将Lua嵌入到C/C++程式中，而用Lua程式作為配置腳本。這種做法的優勢是，Lua語言強大靈活，可以适應 複雜的配置要求。同時，Lua便于嵌入C/C++程式，而且編譯執行速度非常快，可以說是目前解決C/C++程式配置管理問題的一個出色方案。

十四、3D遊戲引擎：

1. Irrlicht http://irrlicht.sourceforge.net/

始于２００３，次年即被評為最佳開源遊戲引擎。官方支援C++和.Net，拓展語言綁定包含java,perl,ruby,python.跨平台支援，使用D3D,OpenGL以及自帶API.

優點：容易上手；跨平台；自帶XML解析器；大的社群；

缺點：最近開發慢下來了

2. Panda3D http://www.panda3d.org/

由迪斯尼開發，卡耐基－梅隆娛娛樂科技中心支援。Python是官方推薦語言。也支援C++。

優點：有用的社群；大量功能；定期開發；

缺點：缺乏工具支援；極差的文檔；

3. OGRE http://www.ogre3d.org/

圖像引擎中最好的一個。２０００年立的項。推薦使用C++語言。需要非常熟悉程式設計才行。初學者不宜。

優點：大量功能；優異的文檔；大規模的社群；活躍的開發

缺點：不适合初哥；隻有圖像引擎

4. Crystal Space http://www.crystalspace3d.org/main/Main_Page

１９９７年發行，用C++編寫的開源遊戲引擎。推薦使用C++

優點：不錯的社群支援；大量功能；

缺點：難學；

5、Delta3d http://www.delta3d.org/index.php

Delta3D是一款由美國海軍研究學院(Naval Postgraduate School)開發的全功能遊戲與仿真引擎，得到美國軍方巨大的支援與豐厚的投資。該引擎應用領域極為廣泛，如開發在教育訓練、教育、娛樂行業和科學計算可視化領域等方面模組化與仿真的軟體。

它的标準化設計把一些知名開源軟體和引擎如 Open Scene Graph(OSG), OpenDynamicsEngine (ODE), Character Animation Library (CAL3D), 還有 OpenAL融為一體。Delta3D通過對這些底層子產品進行隐藏封裝，整合在一起進而形成了一個使用更加友善的進階API 函數庫，使得開發者在必要的時候能夠使用底層函數進行二次開發。Delta3D在軟體系列中，處于中間層(Middle layer)的位置上。

優點：适合各種3D遊戲，仿真，很全面。一直在做更新。

缺點：參考資料比較少。中文文檔也比較少。官方參考資料比較少。但是讀源代碼可以加快了解，應用。

tips：目前，我正在研究delta開源引擎，并利用其開發一個小型遊戲。

順便打個廣告：delta3d 交流qq群：12483772。歡迎加入，共同探讨。

本文版權歸作者 kanego 和部落格園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接配接，否則保留追究法律責任的權利.