SQLite 近日發(fā)表了一篇博文，解釋了為什么多年來 SQLite 一直堅(jiān)持用 C 語言來實(shí)現(xiàn)，以下是正文內(nèi)容：

C 語言是***選擇

從2000年5月29日發(fā)布至今，SQLite 一直都是用 C 語言實(shí)現(xiàn)。C 一直是實(shí)現(xiàn)像 SQLite 這類軟件庫的***語言。目前，還沒有任何計(jì)劃要采用另外一門語言對 SQLite 進(jìn)行重新開發(fā)。

為什么 C 語言是實(shí)現(xiàn) SQLite 的***選擇？原因主要體現(xiàn)在這幾個(gè)方面：

• 性能

• 兼容性

• 低依賴性

• 穩(wěn)定性

1、性能

像 SQLite 這類庫要求速度必須要快。SQLite 的速度就很快，它比文件系統(tǒng)快 35%（詳情可以參考這兩個(gè)示例：Internal Versus External BLOBs 和 35% Faster Than The Filesystem）。

而 C 語言就能實(shí)現(xiàn)快速編寫代碼。C 語言通常被描述為“可移植性的匯編語言”。它使開發(fā)人員能夠盡可能靠近底層硬件進(jìn)行編碼，同時(shí)仍然可以跨平臺保持可移植性。

平常，我們可能會看到有人描述某種語言“像 C 語言一樣快”，卻不會看到有人說，作為通用目的編程時(shí)，會有一門語言“比 C 語言快”，因?yàn)檫@種語言真的不存在。

2、兼容性

幾乎所有系統(tǒng)都能調(diào)用 C 語言編寫的庫，但其他語言就不盡然。例如，用 Java 編寫的 Android 應(yīng)用能夠調(diào)用 SQLite（通過適配器）。 如果用 Java 編寫 SQLite，那么對 Android 來說可能會更方便，因?yàn)檫@會使接口更簡單。但在 iPhone 上，應(yīng)用程序是用 Objective-C 或 Swift 編寫的，它們都不能調(diào)用用 Java 編寫的庫。 因此，如果用 Java 編寫，SQLite 將無法在 iPhone 上使用。

3、低依賴性

用 C 語言編寫的庫對運(yùn)行時(shí)沒有很強(qiáng)的依賴。SQLite 的***配置也只要求 C 庫中的這些方法：

• memcmp()

• memcpy()

• memmove()

• memset()

• strcmp()

• strlen()

• strncmp()

在更完整的構(gòu)建中，SQLite 也使用諸如 malloc() 和 free() 之類的庫例程以及用于打開，讀取，寫入和關(guān)閉文件的操作系統(tǒng)接口。 但即便如此，依賴的數(shù)量也很少。

4、穩(wěn)定性

C 語言易于理解，契合了 SQLite 的要求，適合 SQLite 的開發(fā)。

為什么 SQLite 不使用面向?qū)ο蟮恼Z言？

開發(fā)人員可能無法想象用“非面向?qū)ο?rdquo;來開發(fā)一個(gè)像 SQLite 這樣復(fù)雜的系統(tǒng)會是什么樣子。所以 SQLite 為什么不使用 C++ 或者 Java 來開發(fā)呢？

1、用 C++ 或 Java 編寫的庫通常只能由以相同語言編寫的應(yīng)用程序使用。 使用 Haskell 或 Java 編寫的應(yīng)用程序很難調(diào)用用 C++ 編寫的庫。 另一方面，用 C 語言編寫的庫可以從任何編程語言調(diào)用。

2、面向?qū)ο笫窃O(shè)計(jì)模式，而不是編程語言。 你可以使用任何所需語言（包括匯編語言）進(jìn)行面向?qū)ο缶幊獭?某些語言（例如：C++ 或 Java）可以使面向?qū)ο蟾菀祝闳匀豢梢杂孟?C 這樣的語言進(jìn)行面向?qū)ο蟮木幊獭?/p>

3、面向?qū)ο蟛皇俏ㄒ挥行У脑O(shè)計(jì)模式。對象通常是分解問題的好方法。 但不是唯一的方法，也不總是分解問題的***方法。 有時(shí)好的舊程序代碼更容易編寫，更易于維護(hù)和理解，并且比面向?qū)ο蟮拇a更快。

4、SQLite 進(jìn)行開發(fā)時(shí)，Java 還不是一門成熟的語言，C++ 會成熟一點(diǎn)，但當(dāng)時(shí)要找到兩種能以 相同方式工作的 C++ 編譯器比較困難。相比之下，C 語言是個(gè)不錯(cuò)的選擇。雖然，這種情況現(xiàn)在有所改善，但為此對 SQLite 重新開發(fā)并沒有什么好處。

為什么 SQLite 不使用"安全"語言編寫？

使用“安全”語言不易發(fā)生內(nèi)存泄露、數(shù)組溢出等的安全問題。最近，許多人好像對 Rust 和 Go 這樣的“安全”語言感興趣。但 SQLite 為什么不使用呢？

1、SQLite 出現(xiàn)后的 10 年時(shí)間里，所謂的“安全”語言還不存在。雖然 SQLite 可以用 Rust 或者 Go 重新編寫，但這樣可能會引入更多難以修復(fù)的 Bug，進(jìn)而會影響編碼速度。

2、“安全”編程語言解決簡單的問題：像內(nèi)存泄露、數(shù)組溢出等。在解決 SQL 計(jì)算結(jié)果這類的問題上，并不如 C 語言好用。

3、“安全”語言可防止安全漏洞，但 SQLite 并非一個(gè)對安全敏感的庫。如果應(yīng)用運(yùn)行了不受信任的 SQL，那它可能已經(jīng)存在更大的安全問題，而這是“安全”語言無法修復(fù)的問題。

4、一些“安全”語言（如 Go 語言）不喜歡使用 assert()，但這是保持 SQLite 可維護(hù)性的重要前提。

5、“安全”語言會插入額外的機(jī)器分支來執(zhí)行其他操作。但在正確的代碼中，這些分支并不會被采用。所以機(jī)器代碼不能 100% 被測試到，可這恰恰是 SQLite 質(zhì)量檢測的重要組成部分。

6、“安全”語言會在內(nèi)存不足（OOM）時(shí)請求終止，而 SQLite 的設(shè)計(jì)是遇到 OOM 時(shí)能重新恢復(fù)。目前，還不知道如何利用“安全”語言實(shí)現(xiàn)這一點(diǎn)。

7、現(xiàn)有的“安全”語言都比較新，SQLite 開發(fā)員對它們的出現(xiàn)表示贊賞，但依然認(rèn)為 C 語言更適合目前的開發(fā)工作。

文章***表示，SQLite 可能會考慮使用 Rust 重新開發(fā)，但不太可能使用 Go 語言，因?yàn)樗鼘?nbsp;assert() 不友好。但其實(shí) Rust 目前的條件并不足以對 SQLite 進(jìn)行重新開發(fā)，它還需要繼續(xù)發(fā)展。