
<p class="f_center"><img src="https://nimg.ws.126.net/?url=http%3A%2F%2Fdingyue.ws.126.net%2F2024%2F1029%2F3e698d48j00sm44vz00qvd000v900o5p.jpg&thumbnail=660x&quality=80&type=jpg"/><br/><br/></p><p id="34LPOVAD">SQLite 发表过一篇博文,解释了为什么多年来 SQLite 一直坚持用 C 语言来实现,以下是正文内容:</p><p id="34LPOVAE"><strong>C 语言是**选择</strong></p><p id="34LPOVAF">从2000年5月29日发布至今,SQLite 一直都是用 C 语言实现。C 一直是实现像 SQLite 这类软件库的**语言。目前,还没有任何计划要采用另外一门语言对 SQLite 进行重新开发。</p><p id="34LPOVAG">为什么 C 语言是实现 SQLite 的**选择?原因主要体现在这几个方面:</p><p id="34LPOVAH"><strong>㉿</strong>性能</p><p id="34LPOVAI"><strong>㉿</strong>兼容性</p><p id="34LPOVAJ"><strong>㉿</strong>低依赖性</p><p id="34LPOVAK"><strong>㉿</strong>稳定性</p><p id="34LPOVAL"><strong>1、性能</strong></p><p id="34LPOVAM">像 SQLite 这类库要求<strong>速度必须要快</strong>。SQLite 的速度就很快,它比文件系统快 35%!</p><p id="34LPOVAN">而 C 语言就能实现快速编写代码。C 语言通常被描述为<strong>“可移植性的汇编语言”</strong>。它使开发人员能够尽可能靠近底层硬件进行编码,同时仍然可以跨平台保持可移植性。</p><p id="34LPOVAO">平常,我们可能会看到有人描述某种语言“像 C 语言一样快”,却不会看到有人说,作为通用目的编程时,会有一门语言“比 C 语言快”,因为这种语言真的不存在。</p><p id="34LPOVAP"><strong>2、兼容性</strong></p><p id="34LPOVAQ">几乎所有系统都能调用 C 语言编写的库,但其他语言就不尽然。</p><p><blockquote id="34LPOVBS">例如,用 Java 编写的 Android 应用能够调用 SQLite(通过适配器)。<br/>如果用 Java 编写 SQLite,那么对 Android 来说可能会更方便,因为这会使接口更简单。<br/>但在 iPhone 上,应用程序是用 Objective-C 或 Swift 编写的,它们都不能调用用 Java 编写的库。<br/>因此,如果用 Java 编写,SQLite 将无法在 iPhone 上使用。<br/></blockquote></p><p id="34LPOVAS"><strong>3、低依赖性</strong></p><p id="34LPOVAT">用 C 语言编写的库对运行时没有很强的依赖。SQLite 的最低配置也只要求 C 库中的这些方法:</p><p id="34LPOVAU">▶ memcmp()</p><p id="34LPOVAV">▶ memcpy()</p><p id="34LPOVB0">▶ memmove()</p><p id="34LPOVB1">▶ memset()</p><p id="34LPOVB2">▶ strcmp()</p><p id="34LPOVB3">▶ strlen()</p><p id="34LPOVB4">▶ strncmp()</p><p id="34LPOVB5">在更完整的构建中,SQLite 也使用诸如 malloc() 和 free() 之类的库例程以及用于打开,读取,写入和关闭文件的操作系统接口。 但即便如此,依赖的数量也很少。</p><p id="34LPOVB6"><strong>4、稳定性</strong></p><p id="34LPOVB7">C 语言易于理解,契合了 SQLite 的要求,适合 SQLite 的开发。</p><p id="34LPOVB8"><strong>为什么 SQLite 不使用面向对象的语言?</strong></p><p id="34LPOVB9">开发人员可能无法想象用“非面向对象”来开发一个像 SQLite 这样复杂的系统会是什么样子。所以 SQLite 为什么不使用 C++ 或者 Java 来开发呢?</p><p id="34LPOVBA"><strong>1、</strong>用 C++ 或 Java 编写的库通常只能由以相同语言编写的应用程序使用。</p><p><blockquote id="34LPOVBT">使用 Haskell 或 Java 编写的应用程序很难调用用 C++ 编写的库。 另一方面,用 C 语言编写的库可以从任何编程语言调用。<br/></blockquote></p><p id="34LPOVBC"><strong>2、</strong>面向对象是设计模式,而不是编程语言。</p><p><blockquote id="34LPOVBU">你可以使用任何所需语言(包括汇编语言)进行面向对象编程。 某些语言(例如:C++ 或 Java)可以使面向对象更容易,但你仍然可以用像 C 这样的语言进行面向对象的编程。<br/></blockquote></p><p id="34LPOVBE"><strong>3、</strong>面向对象不是唯一有效的设计模式。</p><p><blockquote id="34LPOVBV">对象通常是分解问题的好方法。,但不是唯一的方法,也不总是分解问题的**方法。 有时好的旧程序代码更容易编写,更易于维护和理解,并且比面向对象的代码更快。<br/></blockquote></p><p id="34LPOVBG"><strong>4、</strong>SQLite 进行开发时,Java 还不是一门成熟的语言,C++ 会成熟一点,但当时要找到两种能以 相同方式工作的 C++ 编译器比较困难。</p><p><blockquote id="34LPOVC0">相比之下,C 语言是个不错的选择。虽然,这种情况现在有所改善,但为此对 SQLite 重新开发并没有什么好处。<br/></blockquote></p><p id="34LPOVBI"><strong>为什么 SQLite 不使用"安全"语言编写?</strong></p><p id="34LPOVBJ">使用“安全”语言不易发生内存泄露、数组溢出等的安全问题。最近,许多人好像对 Rust 和 Go 这样的“安全”语言感兴趣。但 SQLite 为什么不使用呢?</p><p id="34LPOVBK"><strong>1、</strong>SQLite 出现后的 10 年时间里,所谓的“安全”语言还不存在。虽然 SQLite 可以用 Rust 或者 Go 重新编写,但这样可能会引入更多难以修复的 Bug,进而会影响编码速度。</p><p id="34LPOVBL"><strong>2、</strong>“安全”编程语言解决简单的问题:像内存泄露、数组溢出等。在解决 SQL 计算结果这类的问题上,并不如 C 语言好用。</p><p id="34LPOVBM"><strong>3、</strong>“安全”语言可防止安全漏洞,但 SQLite 并非一个对安全敏感的库。如果应用运行了不受信任的 SQL,那它可能已经存在更大的安全问题,而这是“安全”语言无法修复的问题。</p><p id="34LPOVBN"><strong>4、</strong>一些“安全”语言(如 Go 语言)不喜欢使用 assert(),但这是保持 SQLite 可维护性的重要前提。</p><p id="34LPOVBO"><strong>5、</strong>“安全”语言会插入额外的机器分支来执行其他操作。但在正确的代码中,这些分支并不会被采用。所以机器代码不能 100% 被测试到,可这恰恰是 SQLite 质量检测的重要组成部分。</p><p id="34LPOVBP"><strong>6、</strong>“安全”语言会在内存不足(OOM)时请求终止,而 SQLite 的设计是遇到 OOM 时能重新恢复。目前,还不知道如何利用“安全”语言实现这一点。</p><p id="34LPOVBQ"><strong>7、</strong>现有的“安全”语言都比较新,SQLite 开发员对它们的出现表示赞赏,但依然认为 C 语言更适合目前的开发工作。</p><p><blockquote id="34LPOVC1">文章最后表示,SQLite 可能会考虑使用 Rust 重新开发,但不太可能使用 Go 语言,因为它对 assert() 不友好。<br/>但其实 Rust 目前的条件并不足以对 SQLite 进行重新开发,它还需要继续发展...<br/></blockquote></p>
讯享网

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容,请联系我们,一经查实,本站将立刻删除。
如需转载请保留出处:https://51itzy.com/kjqy/140603.html