受 SQLite 多年青睞，C 語言到底好在哪兒？

SQLite 近日發表了一篇博文，解釋了為什麼多年來 SQLite 一直堅持用 C 語言來實現，以下是正文內容：

C 語言是最佳選擇

從 2000 年 5 月 29 日發布至今，SQLite 一直都是用 C 語言實現。C 一直是實現像 SQLite 這類軟體庫的最佳語言。目前，還沒有任何計劃要採用另外一門語言對 SQLite 進行重新開發。

為什麼 C 語言是實現 SQLite 的最佳選擇？原因主要體現在這幾個方面：

性能
兼容性
低依賴性
穩定性

性能

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

而 C 語言就能實現快速編寫代碼。C 語言通常被描述為「可移植性的彙編語言」。它使開發人員能夠儘可能靠近底層硬體進行編碼，同時仍然可以跨平台保持可移植性。

平常，我們可能會看到有人描述某種語言「像 C 語言一樣快」，卻不會看到有人說，作為通用目的編程時，會有一門語言「比 C 語言快」，因為這種語言真的不存在。

兼容性

幾乎所有系統都能調用 C 語言編寫的庫，但其他語言就不盡然。例如，用 Java 編寫的 Android 應用能夠調用 SQLite（通過適配器）。如果用 Java 編寫 SQLite，那麼對 Android 來說可能會更方便，因為這會使接口更簡單。但在 iPhone 上，應用程式是用 Objective-C 或 Swift 編寫的，它們都不能調用用 Java 編寫的庫。因此，如果用 Java 編寫，SQLite 將無法在 iPhone 上使用。

低依賴性

用 C 語言編寫的庫對運行時沒有很強的依賴。SQLite 的最低配置也只要求 C 庫中的這些方法：

memcmp()
memcpy()
memmove()
memset()
strcmp()
strlen()
strncmp()

在更完整的構建中，SQLite 也使用諸如 malloc() 和 free() 之類的庫例程以及用於打開，讀取，寫入和關閉文件的作業系統接口。但即便如此，依賴的數量也很少。

穩定性

C 語言易於理解，契合了 SQLite 的要求，適合 SQLite 的開發。

為什麼 SQLite 不使用面向對象的語言？

開發人員可能無法想像用「非面向對象」來開發一個像 SQLite 這樣複雜的系統會是什麼樣子。所以 SQLite 為什麼不使用 C++ 或者 Java 來開發呢？

用 C++ 或 Java 編寫的庫通常只能由以相同語言編寫的應用程式使用。使用 Haskell 或 Java 編寫的應用程式很難調用用 C++ 編寫的庫。另一方面，用 C 語言編寫的庫可以從任何程式語言調用。
面向對象是設計模式，而不是程式語言。你可以使用任何所需語言（包括彙編語言）進行面向對象編程。某些語言（例如：C++ 或 Java）可以使面向對象更容易，但你仍然可以用像 C 這樣的語言進行面向對象的編程。
面向對象不是唯一有效的設計模式。對象通常是分解問題的好方法。但不是唯一的方法，也不總是分解問題的最佳方法。有時好的舊程序代碼更容易編寫，更易於維護和理解，並且比面向對象的代碼更快。
SQLite 進行開發時，Java 還不是一門成熟的語言，C++ 會成熟一點，但當時要找到兩種能以相同方式工作的 C++ 編譯器比較困難。相比之下，C 語言是個不錯的選擇。雖然，這種情況現在有所改善，但為此對 SQLite 重新開發並沒有什麼好處。

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

使用「安全」語言不易發生內存泄露、數組溢出等的安全問題。最近，許多人好像對 Rust 和 Go 這樣的「安全」語言感興趣。但 SQLite 為什麼不使用呢？

SQLite 出現後的 10 年時間裡，所謂的「安全」語言還不存在。雖然 SQLite 可以用 Rust 或者 Go 重新編寫，但這樣可能會引入更多難以修復的 Bug，進而會影響編碼速度。
「安全」程式語言解決簡單的問題：像內存泄露、數組溢出等。在解決 SQL 計算結果這類的問題上，並不如 C 語言好用。
「安全」語言可防止安全漏洞，但 SQLite 並非一個對安全敏感的庫。如果應用運行了不受信任的 SQL，那它可能已經存在更大的安全問題，而這是「安全」語言無法修復的問題。
一些「安全」語言（如 Go 語言）不喜歡使用 assert()，但這是保持 SQLite 可維護性的重要前提。
「安全」語言會插入額外的機器分支來執行其他操作。但在正確的代碼中，這些分支並不會被採用。所以機器代碼不能 100% 被測試到，可這恰恰是 SQLite 質量檢測的重要組成部分。
「安全」語言會在內存不足（OOM）時請求終止，而 SQLite 的設計是遇到 OOM 時能重新恢復。目前，還不知道如何利用「安全」語言實現這一點。
現有的「安全」語言都比較新，SQLite 開發員對它們的出現表示讚賞，但依然認為 C 語言更適合目前的開發工作。

文章最後表示，SQLite 可能會考慮使用 Rust 重新開發，但不太可能使用 Go 語言，因為它對 assert() 不友好。但其實 Rust 目前的條件並不足以對 SQLite 進行重新開發，它還需要繼續發展，詳情請查看原文。

原文：https://sqlite.org/whyc.html

編譯：開源中國

「徵稿啦」

CSDN 公眾號秉持著「與千萬技術人共成長」理念，不僅以「極客頭條」、「暢言」欄目在第一時間以技術人的獨特視角描述技術人關心的行業焦點事件，更有「技術頭條」專欄，深度解讀行業內的熱門技術與場景應用，讓所有的開發者緊跟技術潮流，保持警醒的技術嗅覺，對行業趨勢、技術有更為全面的認知。

如果你有優質的文章，或是行業熱點事件、技術趨勢的真知灼見，或是深度的應用實踐、場景方案等的新見解，歡迎聯繫 CSDN 投稿，聯繫方式：微信（guorui_1118，請備註投稿+姓名+公司職位），郵箱（guorui@csdn.net）。