C語言是最好的

\\

SQLite在2000年5月29日發布，并一直使用C語言實現。C語言一直是實現SQLite這類軟件庫的最佳語言，目前還沒有計劃使用其他編程語言重新開發SQLite。

\\

C語言是實現SQLite的最佳語言，原因有四：性能、兼容性、低依賴性、穩定性。

\\

性能

\\

像SQLite這樣低級庫速度必須要快。確實，SQLite的速度很快，甚至比文件系統要快上35％。

\\

C語言非常適合用來開發這種對速度有要求的代碼。C語言有時被稱為“可移植的匯編語言”。它讓開發人員能夠盡可能地靠近底層硬件，同時仍然可以保持跨平臺可移植性。

\\

有些語言聲稱自己“與C語言一樣快”，但卻沒有一門語言敢聲稱在作為通用目的編程時比C語言快，因為真的沒有。

\\

兼容性

\\

幾乎所有系統都能夠調用用C語言編寫的庫，但不一定都能調用使用其他語言實現的庫。

\\

例如，使用Java開發的Android應用程序也能調用SQLite（通過適配器）。如果使用Java開發SQLite，那么對Android來說可能會更加方便，因為接口會更簡單。但是，在iPhone上，應用程序是用Objective-C或Swift開發的，它們都不能調用使用Java編寫的庫。因此，如果使用Java開發，SQLite將無法在iPhone上使用。

\\

低依賴性

\\

使用C語言開發的庫沒有太多運行時依賴。SQLite的最低配置只依賴標準C庫的以下幾個例程：memcmp()、strcmp()、memcpy()、strlen()、memmove()、strncmp()、memset()。

\\

對于更完整的版本，SQLite還使用了malloc()和free()之類的例程以及用于打開、讀取、寫入和關閉文件的操作系統接口。但即便如此，依賴項的數量仍然非常少。相比之下，其他“現代”語言通常需要加載數兆字節帶有成千上萬個接口的運行時。

\\

穩定性

\\

C語言陳舊乏味，是一門眾所周知且易于理解的語言。這正好契合了SQLite的要求。如果沒有C語言這樣的語言，開發一個小型、快速、可靠的數據庫引擎是很困難的。

\\

為什么SQLite不使用面向對象語言來開發？

\\

一些程序員無法想象怎么可以使用非“面向對象”的語言來開發像SQLite這樣的復雜系統。那么為什么SQLite沒有用C++或Java來開發？

\\

使用C++或Java編寫的庫通常只能由以相同語言開發的應用程序使用。使用Haskell或Java開發的應用程序很難調用C++庫。反過來，用C語言編寫的庫可以在其他編程語言中調用。\\t

面向對象是一種設計模式，而不是一種編程語言。你可以使用任何語言（包括匯編語言）實現面向對象編程，只是某些語言（例如C++或Java）讓面向對象變成變得更容易而已。但你仍然可以用像C這樣的語言進行面向對象編程。\\t

面向對象并不是唯一有效的設計模式。很多程序員被教導使用純粹的面向對象方式進行思考。對象通常是分解問題的好方法，但對象不是唯一的方法，而且不一定是分解問題的最佳方法。有時候，過程式的代碼更容易編寫，更易于維護和理解，并且比面向對象的代碼運行地更快。\\t

最初在開發SQLite時，Java還只是一門年輕而不成熟的語言。C++比較成熟一些，但正在經歷成長的痛苦時期，當時很難找到兩種能夠以相同方式工作的C++編譯器。所以，在當時C語言絕對是一個更好的選擇?，F在這種情況沒有那么明顯，但現在重新開發SQLite幾乎沒有任何好處。\

為什么SQLite不使用“安全”的編程語言來開發？

\\

最近人們對像Rust或Go這樣的“安全”編程語言很感興趣。在使用這些編程語言時，不太可能或至少很難犯下常見的編程錯誤，如內存泄漏或數組溢出。因此，經常會有人問為什么SQLite不使用“安全”的語言來開發。

\\

在SQLite出現后的頭10年中，所謂的安全的編程語言并不存在。SQLite可以使用Go語言或Rust重新開發，但這樣做可能會引入更多的錯誤，并且也可能導致代碼運行得更慢。\\t

安全的編程語言解決了容易出現的問題：內存泄漏、use-after-free錯誤、數組溢出等。安全語言在解決SQL計算結果這個問題上，不會比普通的C語言代碼提供更多的幫助。\\t

安全語言通常聲稱自己有助于防止安全漏洞。話是沒錯，但SQLite并不是一個對安全特別敏感的庫。如果應用程序運行了不受信任且未經驗證的SQL，那么它已經存在更大的安全問題（SQL注入），沒有哪一門“安全”的語言可以修復這個問題。確實，應用程序有時會從不受信任的來源導入SQLite二進制數據庫文件，這樣可能會帶來潛在的威脅。但是，SQLite中的這種代碼路徑是很有限的，并且經過了良好的測試。SQLite還為希望讀取不受信任數據庫的應用程序提供了預驗證例程，幫助應用程序檢測潛在的威脅。\\t

一些“安全”語言（例如Go語言）不喜歡使用assert()。但是使用assert()是保持SQLite可維護性的重要前提。\\t

安全語言會插入額外的分支邏輯來執行其他一些操作，比如驗證數組訪問是否越界。而在正確的代碼中，永遠不會使用這些分支邏輯。這也意味著機器代碼不會100％被測試到，而這卻恰好是SQLite質量策略的重要組成部分。\\t

安全語言通常希望在遇到內存不足（OOM）時終止運行。SQLite卻被設計成能夠從OOM中正?；謴?。目前還不知道該如何在安全語言中實現這一特性。\\t

現在所有的安全語言都是新生兒。SQLite的開發人員對計算機語言研究人員努力開發更容易、更安全的編程語言表示贊賞，我們鼓勵他們繼續努力下去。但在實現SQLite時，我們對陳舊乏味的C語言更感興趣。\

SQLite可能有一天會使用Rust重新開發。由于Go語言討厭assert()，因此不太可能使用Go語言。但使用Rust也只是一種可能性。如果要使用Rust重新開發SQLite，需要滿足一些先決條件：

\\

Rust需要變得更成熟，減慢演化速度，并且要變得更加陳舊乏味。\\t

Rust需要證明它可以用于構建能夠在所有其他編程語言中調用的通用庫。\\t

Rust需要證明它可以生成適用于嵌入式設備的代碼，包括缺少操作系統的設備。\\t

Rust需要提供可以對二進制文件進行100％分支覆蓋測試的工具。\\t

Rust需要提供一種能夠從OOM錯誤中優雅恢復的機制。\\t

Rust需要證明它可以完成C語言在SQLite中所做的各種工作而不會降低性能。\

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

總結

以上是生活随笔為你收集整理的发布至今18年，为什么SQLite一定要用C语言来开发？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。