SQLite說(shuō)C語(yǔ)言好,到底好在哪里?
C 語(yǔ)言是最佳選擇
從2000年5月29日發(fā)布至今,SQLite 一直都是用 C 語(yǔ)言實(shí)現(xiàn)。C 一直是實(shí)現(xiàn)像 SQLite 這類軟件庫(kù)的最佳語(yǔ)言。目前,還沒(méi)有任何計(jì)劃要采用另外一門(mén)語(yǔ)言對(duì) SQLite 進(jìn)行重新開(kāi)發(fā)。
為什么 C 語(yǔ)言是實(shí)現(xiàn) SQLite 的最佳選擇?原因主要體現(xiàn)在這幾個(gè)方面:
性能
兼容性
低依賴性
穩(wěn)定性
1、性能
像 SQLite 這類庫(kù)要求速度必須要快。SQLite 的速度就很快,它比文件系統(tǒng)快 35%(詳情可以參考這兩個(gè)示例:Internal Versus External BLOBs?和?35% Faster Than The Filesystem)。
而 C 語(yǔ)言就能實(shí)現(xiàn)快速編寫(xiě)代碼。C 語(yǔ)言通常被描述為“可移植性的匯編語(yǔ)言”。它使開(kāi)發(fā)人員能夠盡可能靠近底層硬件進(jìn)行編碼,同時(shí)仍然可以跨平臺(tái)保持可移植性。
平常,我們可能會(huì)看到有人描述某種語(yǔ)言“像 C 語(yǔ)言一樣快”,卻不會(huì)看到有人說(shuō),作為通用目的編程時(shí),會(huì)有一門(mén)語(yǔ)言“比 C 語(yǔ)言快”,因?yàn)檫@種語(yǔ)言真的不存在。
2、兼容性
幾乎所有系統(tǒng)都能調(diào)用 C 語(yǔ)言編寫(xiě)的庫(kù),但其他語(yǔ)言就不盡然。例如,用 Java 編寫(xiě)的 Android 應(yīng)用能夠調(diào)用 SQLite(通過(guò)適配器)。 如果用 Java 編寫(xiě) SQLite,那么對(duì) Android 來(lái)說(shuō)可能會(huì)更方便,因?yàn)檫@會(huì)使接口更簡(jiǎn)單。但在 iPhone 上,應(yīng)用程序是用 Objective-C 或 Swift 編寫(xiě)的,它們都不能調(diào)用用 Java 編寫(xiě)的庫(kù)。 因此,如果用 Java 編寫(xiě),SQLite 將無(wú)法在 iPhone 上使用。
3、低依賴性
用 C 語(yǔ)言編寫(xiě)的庫(kù)對(duì)運(yùn)行時(shí)沒(méi)有很強(qiáng)的依賴。SQLite 的最低配置也只要求 C 庫(kù)中的這些方法:
memcmp()
memcpy()
memmove()
memset()
strcmp()
strlen()
strncmp()
在更完整的構(gòu)建中,SQLite 也使用諸如 malloc() 和 free() 之類的庫(kù)例程以及用于打開(kāi),讀取,寫(xiě)入和關(guān)閉文件的操作系統(tǒng)接口。 但即便如此,依賴的數(shù)量也很少。
4、穩(wěn)定性
C 語(yǔ)言易于理解,契合了 SQLite 的要求,適合 SQLite 的開(kāi)發(fā)。
為什么 SQLite 不使用面向?qū)ο蟮恼Z(yǔ)言?
開(kāi)發(fā)人員可能無(wú)法想象用“非面向?qū)ο蟆眮?lái)開(kāi)發(fā)一個(gè)像 SQLite 這樣復(fù)雜的系統(tǒng)會(huì)是什么樣子。所以 SQLite 為什么不使用 C++ 或者 Java 來(lái)開(kāi)發(fā)呢?
1、用 C++ 或 Java 編寫(xiě)的庫(kù)通常只能由以相同語(yǔ)言編寫(xiě)的應(yīng)用程序使用。 使用 Haskell 或 Java 編寫(xiě)的應(yīng)用程序很難調(diào)用用 C++ 編寫(xiě)的庫(kù)。 另一方面,用 C 語(yǔ)言編寫(xiě)的庫(kù)可以從任何編程語(yǔ)言調(diào)用。
2、面向?qū)ο笫窃O(shè)計(jì)模式,而不是編程語(yǔ)言。 你可以使用任何所需語(yǔ)言(包括匯編語(yǔ)言)進(jìn)行面向?qū)ο缶幊獭?某些語(yǔ)言(例如:C++ 或 Java)可以使面向?qū)ο蟾菀?,但你仍然可以用?C 這樣的語(yǔ)言進(jìn)行面向?qū)ο蟮木幊獭?/p>
3、面向?qū)ο蟛皇俏ㄒ挥行У脑O(shè)計(jì)模式。對(duì)象通常是分解問(wèn)題的好方法。 但不是唯一的方法,也不總是分解問(wèn)題的最佳方法。 有時(shí)好的舊程序代碼更容易編寫(xiě),更易于維護(hù)和理解,并且比面向?qū)ο蟮拇a更快。
4、SQLite 進(jìn)行開(kāi)發(fā)時(shí),Java 還不是一門(mén)成熟的語(yǔ)言,C++ 會(huì)成熟一點(diǎn),但當(dāng)時(shí)要找到兩種能以 相同方式工作的 C++ 編譯器比較困難。相比之下,C 語(yǔ)言是個(gè)不錯(cuò)的選擇。雖然,這種情況現(xiàn)在有所改善,但為此對(duì) SQLite 重新開(kāi)發(fā)并沒(méi)有什么好處。
為什么 SQLite 不使用”安全”語(yǔ)言編寫(xiě)?
使用“安全”語(yǔ)言不易發(fā)生內(nèi)存泄露、數(shù)組溢出等的安全問(wèn)題。最近,許多人好像對(duì) Rust 和 Go 這樣的“安全”語(yǔ)言感興趣。但 SQLite 為什么不使用呢?
1、SQLite 出現(xiàn)后的 10 年時(shí)間里,所謂的“安全”語(yǔ)言還不存在。雖然 SQLite 可以用 Rust 或者 Go 重新編寫(xiě),但這樣可能會(huì)引入更多難以修復(fù)的 Bug,進(jìn)而會(huì)影響編碼速度。
2、“安全”編程語(yǔ)言解決簡(jiǎn)單的問(wèn)題:像內(nèi)存泄露、數(shù)組溢出等。在解決 SQL 計(jì)算結(jié)果這類的問(wèn)題上,并不如 C 語(yǔ)言好用。
3、“安全”語(yǔ)言可防止安全漏洞,但 SQLite 并非一個(gè)對(duì)安全敏感的庫(kù)。如果應(yīng)用運(yùn)行了不受信任的 SQL,那它可能已經(jīng)存在更大的安全問(wèn)題,而這是“安全”語(yǔ)言無(wú)法修復(fù)的問(wèn)題。
4、一些“安全”語(yǔ)言(如 Go 語(yǔ)言)不喜歡使用 assert(),但這是保持 SQLite 可維護(hù)性的重要前提。
5、“安全”語(yǔ)言會(huì)插入額外的機(jī)器分支來(lái)執(zhí)行其他操作。但在正確的代碼中,這些分支并不會(huì)被采用。所以機(jī)器代碼不能 100% 被測(cè)試到,可這恰恰是 SQLite 質(zhì)量檢測(cè)的重要組成部分。
6、“安全”語(yǔ)言會(huì)在內(nèi)存不足(OOM)時(shí)請(qǐng)求終止,而 SQLite 的設(shè)計(jì)是遇到 OOM 時(shí)能重新恢復(fù)。目前,還不知道如何利用“安全”語(yǔ)言實(shí)現(xiàn)這一點(diǎn)。
7、現(xiàn)有的“安全”語(yǔ)言都比較新,SQLite 開(kāi)發(fā)員對(duì)它們的出現(xiàn)表示贊賞,但依然認(rèn)為?C 語(yǔ)言更適合目前的開(kāi)發(fā)工作。