你真的了解 C 和 C++ 標準庫嗎？

我已經(jīng)接觸 C++ 一段時間了，一開始就讓我感到疑惑的是其內(nèi)部結構：我所使用的內(nèi)核函數(shù)和類從何而來？誰發(fā)明了它們？他們是打包在我系統(tǒng)中的某個地方嗎？是否存在一份官方的 C++ 手冊？

在本文中，我將通過從 C 和 C++ 語言的本質(zhì)到實際實現(xiàn)來嘗試回答這些問題。

當我們談論 C 和 C++ 時，實際上是指一組定義（程序）語言應該做些什么，如何表現(xiàn)，應該提供哪些功能的規(guī)則。C/C++ 的編譯器為了處理 C/C++ 編寫的源代碼必須跟隨著這些規(guī)則，并生成二進制應用程序。聽起來非常接近于 HTML:瀏覽器遵循著一組指令，所以它們可以以明確的方式來渲染網(wǎng)頁。

與 HTML 一樣，C 和 C++ 的規(guī)則都是理論上的。國際標準化組織(ISO)的一大群人每年都會聚集幾次來討論和定義語言規(guī)則。沒錯，C 和 C++ 是標準化的東西。他們最終都會得到一本官方的叫標準的書，你可以從他們的網(wǎng)站中購買。隨著語言的發(fā)展新的 papers（指官方的叫標準的書）會被發(fā)布，每一次都定義一個新的標準。這就是為什么我們會有不同的 C 和 C++ 版本的原因：C99, C11, C++03, C++11, C++14 等等，數(shù)字與出版/發(fā)布年份相符。

這些標準都市非常詳細和有技術新的文檔：我不會把它們當作手冊。通常會分為兩部分：

例如，這里有個來自于 C 標準庫第一部分的摘選，它定義了 main 函數(shù)的結構：

1.main 的定義，程序啟動時調(diào)用的函數(shù)。

這是另外一個來自與同樣標準的摘錄，描述了 CAPI 的成員 --fmin 函數(shù)：

2.在 math.h  文件中定義 min 函數(shù)。

如你所見，幾乎沒涉及到代碼。有人必須閱讀標準并將其轉換成計算機可以消化的東西。這是工作于編譯器和（功能）實現(xiàn)上人們所做的：前者是一種可以讀取和處理 C 和 C++ 源文件的工具，后者將標準庫轉換為代碼。我們來深入了解一下。

C 標準庫也稱為 ISO C 庫，是用于完成諸如輸入/輸出處理、字符串處理、內(nèi)存管理、數(shù)學計算和許多其他操作系統(tǒng)服務等任務的宏、類型和函數(shù)的集合。它是在 C 標準中（例如 C11 標準）中定義的。其內(nèi)容分布在不同的頭文件中，比如上面我所提到的 math.h。

和 C 標準庫的概念類似，但僅針對 C++。C++ 標準庫是一組 C++ 模板類，它提供了通用的編程數(shù)據(jù)結構和函數(shù)，如鏈表、堆、數(shù)組、算法、迭代器和任何其他你可以想到的 C++ 組件。C++ 標準庫也包含了 C 標準庫，并在 C++ 標準中進行了定義（例如 C++ 11 標準）。

我們從這里開始討論真正的代碼了。從事于標準庫實現(xiàn)的開發(fā)者閱讀官方的 ISO 規(guī)范并將其轉化為代碼。他們必須依賴其操作系統(tǒng)所提供的功能（讀/寫文件，分配內(nèi)存，創(chuàng)建線程，......所有這些被稱為系統(tǒng)調(diào)用），因此每個平臺都有其自己的標準庫實現(xiàn)。有時它是系統(tǒng)內(nèi)核的一部分，有時它是作為一個附加組件 - 編譯器 - 必須單獨下載。

GNU C 庫，也稱為 glibc, 是 C 標準庫的 GNU 項目實現(xiàn)。并非所有的標準 C 函數(shù)都可以在 glibc 中找到：大多數(shù)數(shù)學函數(shù)實際上是在 libm 庫中實現(xiàn)的，這是一個獨立的庫。

至今，glibc 是 Linux 上使用最廣泛的 C 庫。然而，在 90 年代期間，有一段時間里，glibc 有一個競爭對手稱為 Linux libc（或者簡稱 libc），它是由 glibc 1.x 的一個分支產(chǎn)生的。在一段時間里，Linux libc 是許多 Linux 發(fā)行版中的標準 C 庫。

經(jīng)過多年的發(fā)展，glibc 竟然比 Linux libc 更具優(yōu)勢，并且所有使用它的 Linux 發(fā)行版都切換回了 glibc。所以，如果你在你的磁盤中找到一個名為 libc.so.6 的文件，請不要擔心：它是現(xiàn)代版的 glibc。為了避免與之前的 Linux libc 版本混淆，版本號增加到了 6（他們無法將其命名為 glibc.so.6：所有Linux庫都必須以 lib 前綴打頭）。

另一方面，C++ 標準庫的實現(xiàn)位于 libstdc++ 或 GNU 標準 C++ 庫中。這是一個正在進行的在 GNU/Linux 上實現(xiàn)標準 C++ 庫的項目。一般來說，所有常規(guī)的 Linux 發(fā)行版都默認使用 libstdc++。

在 Mac 和 iOS 上，C 標準庫的實現(xiàn)是 libSystem 的一部分，libSystem 是位于 /usr/lib/libSystem.dylib 中的核心庫。LibSystem 包含其他組件，如數(shù)學庫、線程庫和其他底層實用程序。

關于 C++ 標準庫，在 OS X Mavericks（V10.9）之前的 Mac 上，libstdc++ 是默認選項。這在現(xiàn)代的基于 Linux 的系統(tǒng)上可以找到的同樣的實現(xiàn)。自 OS X Mavericks 開始，Apple 切換到使用 libc++，這是 LLVM 項目——Mac 官方編譯器框架——所引入的 GNU libstdc++ 標準庫的替代。

IOS 開發(fā)者可以使用 iOS SDK（軟件開發(fā)工具包）來訪問標準庫，它是一系列允許創(chuàng)建移動應用程序的工具。

在 Windows 上，標準庫的實現(xiàn)一直嚴格限定在 Visual Studio 中，它是微軟官方的編譯器。他們通常稱之為 C/C++ 運行時庫（CRT），并且它涵蓋了 c/c++ 二者的實現(xiàn)。

在最開始，CRT 被實現(xiàn)為 CRTDLL.DLL 庫（我猜，當時沒有可用的 C++ 標準庫）。從 Windows 95 開始，Microsoft 開始將其遷移到 MSVCRT [版本號] .DLL（MSVCR20.DLL，MSVCR70.DLL 等）之上，據(jù)推測也包含 C++ 標準庫。在 1997 年，他們決定將文件名簡化為  MSVCRT.DLL，這不幸導致了令人討厭的DLL混亂。這就是為什么從 Visual Studio 7.0 版開始，他們切換回每個版本使用單獨的 DLL 了。

Visual Studio 2015 引入了深度的 CRT 重構。C/C++ 標準庫的實現(xiàn)遷移到一個新庫，Universal C 運行時庫 (Universal CRT 或 UCRT)，編譯為 UCRTBASE.DLL。UCRT 目前已經(jīng)成為 Windows 組之一，從 Windows 10 開始作為操作系統(tǒng)的一部分提供。

Bionic 是 Google 為其 Android 操作系統(tǒng)所編寫的 C 標準庫實現(xiàn)，它直接在底層使用。第三方開發(fā)者可以通過 Android 原生開發(fā)工具包（NDK）訪問 Bionic，該工具集允許你使用 C 和 C++ 代碼編寫 Android 應用程序。

在 C++ 端, NDK 提供了很多版本的實現(xiàn)：

如果你正在使用資源非常有限的系統(tǒng)，則通常需要引用 C 標準庫的不同實現(xiàn)。比如，uClibc-ng, musl libc 和 diet libc 等等，所有這些都適用于嵌入式 Linux 系統(tǒng)的開發(fā)，提供更小的二進制文件和更少的內(nèi)存占用。

C++ 標準庫也有不同的實現(xiàn)版本：Apache C++ 標準庫，uSTL 以及 EASTL 等等。后面兩個實際上僅關注模板部分，而不是完整的庫，并且他們是在速度優(yōu)先的情況下開發(fā)的。Apache 版本的庫注重的是可移植性。

不使用標準庫很簡單：只要在你的程序中不引入它們的任何一個頭文件，你的工作就完成了。然而，為了讓這個操作更有意義一些，你需要通過一些提供的系統(tǒng)調(diào)用使用某種方法與操作系統(tǒng)互動。就像我之前說的，這就是標準庫中的函數(shù)/方法在底層實現(xiàn)的時候所使用的。很可能你也會不得不調(diào)用這些方法來與硬件設備交互。

如果對你來說這聽起來很讓人激動，有些人已經(jīng)開始在網(wǎng)上嘗試在不導入標準庫的情況下創(chuàng)建工作流程。因為你依賴于一個特定操作系統(tǒng)所提供的函數(shù)，這種方式會喪失可移植性。然而通過使用這種艱難的方式，肯會讓你學到更多，而且讓你更好的理解當你所做的事情，即使是在使用高級庫的時候。

除了知識，當你在嵌入式操作系統(tǒng)上面工作的時候你不會想去引入標準庫：因為代碼不需要移植，在有限的內(nèi)存中每個字節(jié)都很重要，這會讓你更加精準的寫代碼。另一個使用背景就是 demoscene，在這里人們盡量有限的程序的二進制大小中去保留高質(zhì)量的音視頻——4K仍然不是最小值：一些 demoparties 使用 1K，256 字節(jié)，64 字節(jié)或者甚至 32 字節(jié)來競爭。在那里不允許使用標準庫！

原文：www.oschina.net/translate/c-c-standard-library