前些日子微軟推出了Visual Studio系列的C++類庫和GNU陣營的壓軸產品gc中的g++，這可大大的使編程人員和一些搞開發的人興奮不已，對於C++類庫的設計開發者來說，保持C++的高性能是一個重要目標。
我們在開篇就對簡單性目標作了敘述，這裡再稍微展開討論一下。我們提出的簡單標准，首先是外部接口簡單，其次是內部結構簡單。我們知道，類庫是提供給上層應用程序使用的，也就是按照一定的接口規范，向上層提供一定的功能服務。
接口設計得越簡單，對上層用戶來說就越方便，就越不容易產生Bug。我們可以注意到，流行的成功類庫都是擁有簡單接口的。為了使接口簡單，常常不得不把有關具體實現的復雜性封裝於類庫內部，也就是說，關於簡單性的設計原則，外部接口簡單優先於內部實現簡單。
高性能是C++語言優於其它OO語言的一個特性。C++的高性能應該首先歸於它運行模式，和大多數OO語言不同，C++程序編譯後直接產生本地平台代碼Native Code），理論上具備了可能的最大執行性能。另外的一個原因是主流的C++編譯器都被設計得非常精巧，具有優越的代碼優化能力。
對於C++類庫設計者來說，保持C++的高性能是一個重要目標。程序的高性能可以從兩方面來評價，一是時間性能，以盡量短的時間來解決盡量多的業務；二是資源性能，以盡量少的資源消耗，包括CPU使用、內存占用、網絡流量、磁盤空間等等，來維持正常的程序功能。提高性能的主要手段是數據結構、算法和程序體現結構的優化設計000-861 117-102 。
再說可移植性。C++的編譯後輸出代碼是本地平台代碼，因此C++本身不具有目標代碼可移植性，C++的可移植性只能是源代碼可移植性。源代碼的可移植性是指，同一軟件產品的全部或者部分源代碼可以在不同的編譯環境中進行編譯不需要編譯的除外）。
並且其結果具有相同的品質特性依優先順序包括功能性、可靠性、可用性、性能性、可維護性等）。編譯環境可以大致分為三個層次，最底層的是操作系統，也就是平台Platform），其次是對源代碼直接進行處理的編譯器，然後是其它在編譯過程中必需的中間件物品。
如庫文件等。我們知道C++雖然在語言規范上獲得了統一ISO/IEC），其編譯器卻是群雄割據的局面，具有代表性的有Borland C++系列已經淡出市場），Microsoft的Visual Studio系列的C++類庫和GNU陣營的壓軸產品gc中的g++。
源代碼經編譯環境處理後產生的可執行代碼的執行平台稱為目標平台，不同的編譯器的目標平台也不同，有的支持多平台，如g++，有的是單一平台，如Visual C++。對於類庫設計者來說。
想要獲得完全的可移植性是非常困難的除非是象STL這樣被納入語言規范的類庫，因為不支持STL就是不支持標准的C++。即便如此不同的編譯環境還是存在不同的STL實現版本，造成“一個類庫多個實現”的局面），我們只能有選擇地支持一部分環境。我們在開篇就已經說明，我們選擇g++和Visual C++編譯器，選擇Linux和Windows 32位目標平台。
想要獲得完全的可移植性是非常困難的除非是象STL這樣被納入語言規范的類庫，因為不支持STL就是不支持標准的C++。即便如此不同的編譯環境還是存在不同的STL實現版本，造成“一個類庫多個實現”的局面），我們只能有選擇地支持一部分環境。我們在開篇就已經說明，我們選擇g++和Visual C++編譯器，選擇Linux和Windows 32位目標平台。
一個解決辦法是將庫文件保持在源代碼形態包括頭文件和源文件），而不編譯成二進制文件。比如STL的許多實現版本都是以頭文件形式存在。這樣雖然解決了名稱裝飾所帶來的不可移植問題，但同時又會帶來代碼編譯時間增長，源代碼完全公開等問題。在C++的名稱裝飾規則未被統一之前，看起來這個問題是很難兩全其美地解決了。
在本系列中，我們也仿照g++的STL實現方式，完全以頭文件形式來編寫類庫。為什麼不把代碼放到源文件中去呢？主要原因是，頭文件只需要用戶使用包含指令#include）就可以處理了，而源文件則需要配置到用戶工程的編譯目標列表中，和用戶的源程序形成共同編譯的形式，破壞了用戶工程的編譯目標的封閉性，比較麻煩而且不符合軟件開發的一般習慣。
編輯推薦】
