首先說指導思想。這是一個價值觀問題，我們在此提出三條標準：簡單，高性能，可移植。
我們在開篇就對簡單性目標作了敘述，這里再稍微展開討論一下。我們提出的簡單標準，首先是外部接口簡單，其次是內部結構簡單。我們知道，類庫是提供給上層應用程序使用的，也就是按照一定的接口規范，向上層提供一定的功能服務。接口設計得越簡單，對上層用戶來說就越方便，就越不容易產生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位目標平臺。
接下來我們來討論C++類庫設計的方法論。
首先，我們采用僅用頭文件的類庫設計方式（Header-only，STL的大多數實現版本都是采用Header-only的方式），也就是在頭文件（.h）中聲明和定義類，將其成員函數全部定義為內聯函數，而不使用源程序文件（.cpp）。
我們知道在C語言的開發環境中，所謂庫文件包含兩個部分，頭文件部分和二進制文件部分。根據二進制文件和用戶目標文件結合方式的不同，又可分為靜態鏈接文件和動態鏈接文件。這種庫的構成模式已成為事實上的C語言開發環境的標準，絕大多數平臺、絕大多數編譯器都使用這種模式 117-301 190-721 。
然而C++語言開發環境，這種庫構成模式遭遇到一個重大問題，就是符號命名問題。舉例來說，C++允許多個函數可以被重載(Overload)，可以具有相同的名稱，而通過參數列表不同被予以區別。這樣就帶來一個問題，編譯完成的目標代碼中怎樣來區別這些在源代碼中具有相同名稱的函數？常見的做法是在編譯器輸出的函數的符號名稱中加入描述類型信息的字符串，這種方法通常被稱為名稱裝飾（Name decoration）或者名稱糟化（Name mangling，這個術語真不好翻譯，筆者的感覺是發明這個詞的人覺得編譯器把本來簡單干凈的符號給搞亂了）。比如說，g++3.4.4對于函數void func(int),其編譯輸出符號名稱為_Z1funci，對于函數void func(int, int)，其輸出符號名稱為_Z1funcii，等等。但是，這種名稱裝飾規則沒有統一規范，也就是說不同的編譯器有各自不同的名稱裝飾規則，這樣就導致不同的C++編譯器只能識別自己的輸出文件，而沒有辦法處理其他編譯器的輸出文件。因此，如果將C++程序制作成二進制的庫文件，則其能夠支持的開發環境只能限于原始的開發環境，基本上不具有多種開發環境間的通用性。
一個解決辦法是將庫文件保持在源代碼形態（包括頭文件和源文件），而不編譯成二進制文件。比如STL的許多實現版本都是以頭文件形式存在。這樣雖然解決了名稱裝飾所帶來的不可移植問題，但同時又會帶來代碼編譯時間增長，源代碼完全公開等問題。在C++的名稱裝飾規則未被統一之前，看起來這個問題是很難兩全其美地解決了。
在本系列中，我們也仿照g++的STL實現方式，完全以頭文件形式來編寫類庫。為什么不把代碼放到源文件中去呢？主要原因是，頭文件只需要用戶使用包含指令（#include）就可以處理了，而源文件則需要配置到用戶工程的編譯目標列表中，和用戶的源程序形成共同編譯的形式，破壞了用戶工程的編譯目標的封閉性，比較麻煩而且不符合軟件開發的一般習慣。
其次我們來討論如何支持多平臺。我們已經說過在本系列中我們的線程庫支持Linux平臺的Posix線程和Windows 32位平臺的線程模式。我們可以參考C++的Pimpl“慣語”(Pimpl idiom，在Herb Sutter的《Exceptional C++》中有介紹)，采用2層類構造方式。上次類亦即接口類，為用戶提供統一的類接口，在用戶看來具有唯一的類行為定義；下層類亦即實現類，將接口類的行為定義轉化為某個平臺的具體實現。