小巧。快速。可靠。
任選三項。
為什麼 SQLite 使用 C 編寫
► 目錄

1. C 最佳

注意：本文的第 2.0 和 3.0 節是針對 Hacker News 和 Reddit 上的留言而新增。

自 2000-05-29 誕生以來，SQLite 一直使用通用 C 實作。C 一直是，而且持續是實作類似 SQLite 這樣的軟體函式庫的最佳語言。目前沒有任何計畫使用其他程式語言重新編寫 SQLite。

C 是實作 SQLite 的最佳語言的原因包括

1.1. 效能

像 SQLite 這樣大量使用的低階函式庫需要快速。（例如，SQLite 很快，請參閱 內部與外部 BLOB 和 比檔案系統快 35%。）

C 是撰寫快速程式碼的絕佳語言。C 有時被描述為「可攜式的組譯語言」。它讓開發人員能夠盡可能接近底層硬體編寫程式碼，同時仍然可以在不同平台上移植。

其他程式語言有時聲稱「和 C 一樣快」。但沒有其他語言聲稱在一般用途程式設計中比 C 更快，因為沒有任何語言比 C 快。

1.2. 相容性

幾乎所有系統都可以呼叫用 C 編寫的函式庫。其他實作語言則不然。

因此，例如，以 Java 編寫的 Android 應用程式能夠呼叫 SQLite（透過一個轉接器）。如果 SQLite 是以 Java 編碼，這可能會讓 Android 更加方便，因為這會讓介面更簡單。然而，iPhone 應用程式是以 Objective-C 或 Swift 編碼，這兩種語言都沒有呼叫以 Java 編寫的函式庫的能力。因此，如果 SQLite 是以 Java 編寫，它將無法在 iPhone 上使用。

1.3. 低依賴性

以 C 編寫的函式庫沒有龐大的執行時間依賴性。在最低限度的組態中，SQLite 只需要標準 C 函式庫中的以下常式

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

在更完整的建置中，SQLite 也使用函式庫常式，例如 malloc() 和 free()，以及用於開啟、讀取、寫入和關閉檔案的作業系統介面。但即使如此，依賴項的數量也很少。相比之下，其他「現代」語言通常需要載入數千個介面的多百萬位元組執行時間。

1.4. 穩定性

C 語言既古老又無聊。這是一種眾所周知且廣為理解的語言。這正是開發類似 SQLite 的模組時所需要的。撰寫一個小巧、快速且可靠的資料庫引擎已經夠困難了，而實作語言並不會隨著實作語言規格的每次更新而改變。

2. 為什麼 SQLite 沒有以物件導向語言編碼？

有些程式設計師無法想像在不是「物件導向」的語言中開發像 SQLite 這樣複雜的系統。那麼為什麼 SQLite 沒有以 C++ 或 Java 編碼？

  1. 以 C++ 或 Java 編寫的函式庫通常只能由以相同語言編寫的應用程式使用。要讓以 Haskell 或 Java 編寫的應用程式呼叫以 C++ 編寫的函式庫很困難。另一方面，以 C 編寫的函式庫可以從任何程式語言呼叫。

  2. 物件導向是一種設計模式，而不是一種程式語言。您可以在任何想要的語言中進行物件導向程式設計，包括組譯語言。有些語言（例如：C++ 或 Java）讓物件導向變得更容易。但您仍然可以在 C 等語言中進行物件導向程式設計。

  3. 物件導向並非唯一有效的設計模式。許多程式設計師都被教導純粹以物件來思考。而且，公平地說，物件通常是分解問題的好方法。但物件並非唯一的方法，而且並非總是分解問題的最佳方法。有時，良好的舊式程序碼更容易撰寫、維護和理解，而且比物件導向程式碼更快。

  4. 當 SQLite 最初在開發時，Java 是一種年輕且不成熟的語言。C++ 較舊，但正在經歷成長的痛苦，因此很難找到任何兩個以相同方式運作的 C++ 編譯器。因此，當 SQLite 最初在開發時，C 絕對是更好的選擇。現在情況較不嚴重，但在這一點上重新編寫 SQLite 幾乎沒有好處。

3. 為何 SQLite 未以「安全」語言編寫？

最近對「安全」程式語言（例如 Rust 或 Go）產生了濃厚的興趣，在這些語言中，不可能或至少很難發生常見的程式設計錯誤，例如記憶體洩漏或陣列溢位。因此，經常會出現為何 SQLite 未以「安全」語言編寫的問題。

  1. 在 SQLite 存在的頭 10 年中，沒有任何安全的程式語言存在。SQLite 可以用 Go 或 Rust 重新編寫，但這樣做可能會引入比修復的錯誤更多，而且似乎也可能導致程式碼變慢。

  2. 安全的語言會插入額外的機器分支來執行一些事情，例如驗證陣列存取是否在界限內。在正確的程式碼中，那些分支永遠不會被執行。這表示機器碼無法進行 100% 分支測試，而這是 SQLite 品質策略的重要組成部分。

  3. 安全的語言通常希望在遇到記憶體不足 (OOM) 情況時中止。SQLite 則設計為能從 OOM 中優雅地復原。目前尚不清楚這如何在現有的安全語言中達成。

  4. 所有現有的安全語言都是新的。SQLite 的開發人員讚賞電腦語言研究人員在嘗試開發更易於安全編寫程式的語言所做的努力。我們鼓勵這些努力持續下去。但我們自己對於在實作 SQLite 時，更感興趣的是古老且無聊的語言。

儘管如此，SQLite 有可能在某天以 Rust 重新編寫。以 Go 重新編寫 SQLite 的可能性很低，因為 Go 討厭 assert()。但 Rust 是個可能性。在以 Rust 重新編寫 SQLite 之前必須符合的一些先決條件包括

  1. Rust 需要再成熟一點，停止如此快速地變更，並朝著古老且無聊的方向更進一步。
  2. Rust 需要證明它可以用於建立可從所有其他程式語言呼叫的通用函式庫。
  3. Rust 需要證明它可以產生在晦澀的嵌入式裝置上運作的物件碼，包括缺乏作業系統的裝置。
  4. Rust 需要採用必要的工具，讓使用者能夠對已編譯的二進位檔進行 100% 分支覆蓋率測試。
  5. Rust 需要一種機制來從 OOM 錯誤中優雅地復原。
  6. Rust 需要證明它可以執行 SQLite 中 C 所做的工作類型，而不會顯著降低速度。

如果您是「rustacean」，並且認為 Rust 已符合上述先決條件，且 SQLite 應該以 Rust 重新編寫，那麼歡迎且鼓勵您私下聯絡 SQLite 開發人員並提出您的論點。

此頁面最後修改於 2022-07-29 00:41:26 UTC