C語言是最好的

\\

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

\\

C語言是實(shí)現(xiàn)SQLite的最佳語言，原因有四：性能、兼容性、低依賴性、穩(wěn)定性。

\\

性能

\\

像SQLite這樣低級(jí)庫速度必須要快。確實(shí)，SQLite的速度很快，甚至比文件系統(tǒng)要快上35％。

\\

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

\\

有些語言聲稱自己“與C語言一樣快”，但卻沒有一門語言敢聲稱在作為通用目的編程時(shí)比C語言快，因?yàn)檎娴臎]有。

\\

兼容性

\\

幾乎所有系統(tǒng)都能夠調(diào)用用C語言編寫的庫，但不一定都能調(diào)用使用其他語言實(shí)現(xiàn)的庫。

\\

例如，使用Java開發(fā)的Android應(yīng)用程序也能調(diào)用SQLite（通過適配器）。如果使用Java開發(fā)SQLite，那么對(duì)Android來說可能會(huì)更加方便，因?yàn)榻涌跁?huì)更簡單。但是，在iPhone上，應(yīng)用程序是用Objective-C或Swift開發(fā)的，它們都不能調(diào)用使用Java編寫的庫。因此，如果使用Java開發(fā)，SQLite將無法在iPhone上使用。

\\

低依賴性

\\

使用C語言開發(fā)的庫沒有太多運(yùn)行時(shí)依賴。SQLite的最低配置只依賴標(biāo)準(zhǔn)C庫的以下幾個(gè)例程：memcmp()、strcmp()、memcpy()、strlen()、memmove()、strncmp()、memset()。

\\

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

\\

穩(wěn)定性

\\

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

\\

為什么SQLite不使用面向?qū)ο笳Z言來開發(fā)？

\\

一些程序員無法想象怎么可以使用非“面向?qū)ο蟆钡恼Z言來開發(fā)像SQLite這樣的復(fù)雜系統(tǒng)。那么為什么SQLite沒有用C++或Java來開發(fā)？

\\

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

面向?qū)ο笫且环N設(shè)計(jì)模式，而不是一種編程語言。你可以使用任何語言（包括匯編語言）實(shí)現(xiàn)面向?qū)ο缶幊?#xff0c;只是某些語言（例如C++或Java）讓面向?qū)ο笞兂勺兊酶菀锥选５闳匀豢梢杂孟馛這樣的語言進(jìn)行面向?qū)ο缶幊?。\\t

面向?qū)ο蟛⒉皇俏ㄒ挥行У脑O(shè)計(jì)模式。很多程序員被教導(dǎo)使用純粹的面向?qū)ο蠓绞竭M(jìn)行思考。對(duì)象通常是分解問題的好方法，但對(duì)象不是唯一的方法，而且不一定是分解問題的最佳方法。有時(shí)候，過程式的代碼更容易編寫，更易于維護(hù)和理解，并且比面向?qū)ο蟮拇a運(yùn)行地更快。\\t

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

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

\\

最近人們對(duì)像Rust或Go這樣的“安全”編程語言很感興趣。在使用這些編程語言時(shí)，不太可能或至少很難犯下常見的編程錯(cuò)誤，如內(nèi)存泄漏或數(shù)組溢出。因此，經(jīng)常會(huì)有人問為什么SQLite不使用“安全”的語言來開發(fā)。

\\

在SQLite出現(xiàn)后的頭10年中，所謂的安全的編程語言并不存在。SQLite可以使用Go語言或Rust重新開發(fā)，但這樣做可能會(huì)引入更多的錯(cuò)誤，并且也可能導(dǎo)致代碼運(yùn)行得更慢。\\t

安全的編程語言解決了容易出現(xiàn)的問題：內(nèi)存泄漏、use-after-free錯(cuò)誤、數(shù)組溢出等。安全語言在解決SQL計(jì)算結(jié)果這個(gè)問題上，不會(huì)比普通的C語言代碼提供更多的幫助。\\t

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

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

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

安全語言通常希望在遇到內(nèi)存不足（OOM）時(shí)終止運(yùn)行。SQLite卻被設(shè)計(jì)成能夠從OOM中正常恢復(fù)。目前還不知道該如何在安全語言中實(shí)現(xiàn)這一特性。\\t

現(xiàn)在所有的安全語言都是新生兒。SQLite的開發(fā)人員對(duì)計(jì)算機(jī)語言研究人員努力開發(fā)更容易、更安全的編程語言表示贊賞，我們鼓勵(lì)他們繼續(xù)努力下去。但在實(shí)現(xiàn)SQLite時(shí)，我們對(duì)陳舊乏味的C語言更感興趣。\

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

\\

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

Rust需要證明它可以用于構(gòu)建能夠在所有其他編程語言中調(diào)用的通用庫。\\t

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

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

Rust需要提供一種能夠從OOM錯(cuò)誤中優(yōu)雅恢復(fù)的機(jī)制。\\t

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

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。